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ABSTRACT 


As  hardware  complexity  increases,  software  complexity 
increases,  and  software  systems  become  less  maintainable  by 
manual  methods.  Automated  software  development  methods,  like 
Rapid  Prototyping,  have  served  to  increase  the  maintainability 
of  modern  software  systems,  and  increase  customer 
participation  in  the  requirements  definition  process.  This 
makes  software  systems  more  maintainable  and  increases 
customer  satisfaction  with  the  first  version  of  the  system. 
Still,  changes  are  inevitable.  The  part  of  the  maintenance 
problem  that  automated  tools  currently  do  not  address,  is  the 
automatic  propagation  of  changes  through  multiple  versions  of 
the  same  system. 

The  Prototype  System  Description  Language  (P5DL)  is  a 
language  used  exclusively  for  designing  and  executing  rapid 
prototypes.  This  thesis  is  directed  at  developing  a  model  for 
automatically  merging  two  different  versions  of  a  PSDL 
program,  providing  a  method  for  propagating  changes  through 


multiple  versions  of  that  program. 


Accession  Tor 

"TIS  GRAH  ~ 
DTIC  TAB 
Unannounced 
Just  1  float  i  o£L_ 


D1 strjbut l on/ 
Avallabi  llty  Codos 
jkAvfiii  and/or 
!-st  f  Special 


no 


TABLE  OF  CONTENTS 


I.  INTRODUCTION . 1 

A.  SOFTWARE  MAINTENANCE . 2 

1.  Model  For  Software  Manufacture . 3 

2.  Model  For  Software  Maintenance . 5 

B.  RAPID  PROTOTYPING . 9 

C.  COMPUTER-AIDED  PROTOTYPING  SYSTEM . 10 

D.  PROTOTYPING  SYSTEM  DESCRIPTION  LANGUAGE . 13 

E.  CHANGE  PROPAGATION . 15 

II.  PREVIOUS  WORK . 18 

A.  MERGING  SOFTWARE  EXTENSIONS . 18 

1.  Extensions  vs.  Modifications . 18 

2.  Definitions . 21 

3.  Program  Merging . 24 

B.  AN  ALGORITHM  FOR  INTEGRATING  PROGRAM 

MODIFICATIONS . 2  7 

1.  Program  Dependence  Graphs . 2  8 

2.  Program  Slicing . 32 

3.  Program  Semantics  and  Program  Dependence 

Graphs . 32 

4.  Determining  Behavior  Differences  in 

Variants . 35 

5.  Merging  Program  Dependence  Graphs . 36 

6.  Determining  Interference  Between 

Modifications . 36 

7.  Program  Reconstitution . 37 


iv 


C.  SUMMARY . 37 

III.  A  MODEL  FOR  MERGING  PSDL  PROGRAMS . 39 

A.  SPECIFICATIONS . 43 

1.  Interfaces . 43 

a.  Ordered  Sets . 43 

(1)  Input  and  Output . 45 

(2)  Generic  Parameters . 47 

b.  Unordered  Sets . 47 

(1)  States . 47 

(2)  Exceptions . 49 

(3)  Timing  Information . 51 

2.  Functionality . 52 

a.  Keywords . 53 

b.  Informal  Description . 53 

c.  Formal  Description . 53 

B.  DATA  FLOW  DIAGRAMS . 53 

C.  DATA  STREAMS  AND  CONTROL  CONSTRAINTS . 5  9 

1.  Data  Streams . 59 

2.  Control  Constraints . 59 

D.  CORRECTNESS  OF  CHANGE-MERGE  OPERATION . 63 

1.  Consistency  of  Model . 63 

2.  Semantic  Properties  of  the  Model . 64 

E.  SUMMARY . 66 

IV.  CONCLUSION . 67 

A.  BENEFITS  TO  SOFTWARE  ENGINEERING . 67 

B.  BENEFITS  TO  CAPS  RESEARCH . 68 


v 


c. 


FURTHER  RESEARCH 


69 


APPENDIX  A  (P SDL  GRAMMAR) . 70 

APPENDIX  B  (PROOF:  CONSISTENCY  OF  CHANGE-MERGE  THEOREM)  ...  74 

LIST  OF  REFERENCES . 81 

GLOSSARY . 82 


BIBLIOGRAPHY 


84 


INITIAL  DISTRIBUTION  LIST 


85 


vi 


LIST  OF  FIGURES 


1.  Sample  Configuration  in  The  Model  for 

Software  Maintenance . 7 

2.  The  Prototyping  Life-Cycle  Model . 11 

3.  Computer-Aided  Prototyping  System  Tools . 12 

4.  The  Notion  of  Change  Propagation 

Represented  Graphically . 16 


5.  The  Idea  of  Merging  Two  Different  Versions  of  a 
Base  Program  into  a  Merged  Program  with  the 
Significant  Capabilities  of  Both  Versions  is 


Similar  to  Propagating  Changes . 17 

6.  Example:  Program  Approx  Diverges  if  y  =  0 . 19 

7.  Example:  Program  Approx_l  is  a  Compatible 
Extension  of  Approx  Which  is  Defined  for 

All  Inputs . 19 

8.  Example:  Program  Approx_2  Uses  a  Different 

Approximation  Method . 20 

9.  Definitions  of  Relevant  Domains . 21 

10.  Domains  for  Functions  and  Specifications . 23 

11.  Definitions  of  Domain  and  Satisfy . 23 

12.  Example:  A  Specification  for  a  Square  Root 

Function . 24 

13.  Correctness  Theorem . 25 

14.  Example:  A  Merge  Using  Rewrite  Rules . 27 

15.  Example:  A  Simple  Program  to  Illustrate 

Program  Dependence  Graphs . 31 

16.  Example:  The  Program  Dependence  Graph  for 

the  Program  nada . 31 

17.  Example:  The  Slice  of  the  Program  nada 

Taken  With  Respect  to  x . 33 


VI  1 


18. 

19. 

20. 
21. 

22. 
23. 
24  . 

25. 

26. 

27. 

28. 

29. 

30. 

31. 

32  . 

33  . 

34. 

35. 


Example:  Program  Dependence  Graph 

for  nada_x . 33 

Strong  Equivalence  Theorem . 34 

Slicing  Theorem . 34 

The  Set  of  All  PSDL  Operators  Forms  a 

Lattice . 41 

Ordered  Sets  Have  a  Flat  Lattice  Structure . 44 

Example:  An  Interface  Merge . 46 

A  Merge  of  Generic  Parameters . 48 

Unordered  Sets  Have  a  Powerset  Lattice 

Structure . 4  9 

Example:  A  Merge  of  Two  State  Variable 

Interfaces . 50 

Example:  Merging  Exception  Sets . 51 

Examples:  Merging  Timing  Information . 52 

Example:  PSDL  Operator  Data  Flow  Diagrams . 55 

Example:  Corresponding  Bipartite  Graphs  for 

Examples  in  Figure  2  9 . 56 

Example:  Merge  Operation  on  Data  Flow 

Diagrams . 57 

Graphical  Illustrations  for  the  Merging 

Operation  in  Figure  31 . 58 

Start  and  Stop  Timer  Operations  are  Merged 

Using  a  Flat  Lattice  Ordering  Relation . 61 

Example:  A  Merge  of  Control  Constraints . 62 

Consistency  of  Change-merge . 65 


viii 


LIST  OF  SYMBOLS 


G 


<=> 


T 

1 

3 

V 

n 

u 

II 

IJ 

L 


Is  Equivalent  To 

Is  an  Element  Of 

Logical  Negation 

Logical  Implication 

If  and  Only  If/Logical  Equivalence 

Logical  And 

Logical  Or 

Top/ Inconsistent 

Bottom/ Unde fined 

There  Exists  At  Least  One 

For  All  Elements 

Set  Intersection 

Set  Union 

Set  Difference 

Greatest  Common  Approximation 
Least  Common  Extension 
Approximates 


IX 


ACKNOWLEDGEMENT 


I  would  like  to  thank  my  wife  Caryn  for  her  unselfish 
support  during  these  last  twenty-two  months.  She  has  been 
very  loving  and  understanding,  and  without  her  support,  I 
would  never  have  maintained  my  sanity.  I  would  also  like  to 
thank  Dr.  Berzins  and  Dr.  Luqx  for  their  patience  and 
perserverance .  Without  their  guidance,  I  would  not  understand 
half  of  what  I  have  done. 

During  the  course  of  doing  this  thesis,  I  have  learned  a 
tremendous  amount  about  applied  mathematics  and  abstract 
algebra  that  I  never  knew  existed.  I  have  come  much  farther 
than  I  ever  expected,  and  now,  only  a  fraction  of  the  distance 
I  want  to  go. 


x 


I .  INTRODUCTION 


Software  Development  is  an  ever-increasing  and  complex 
industry.  As  hardware  technology  gains  sophistication,  so 
must  the  software  that  drives  it.  In  the  1960's,  IBM 
developed  OS/360.  It  has  been  reported  that  it  took  5000 
person-years  to  develop  and  document  that  system. [Ref .  1] 

Since  then,  hardware  has  become  even  more  complex.  It  has 
been  said  that  the  software  needed  to  operate  the  Strategic 
Defense  Initiative  Systems  will  far  exceed  ten  million  lines 
of  code.  [Ref.  2]  With  software  systems  that  sophisticated, 
it  is  easy  to  see  that  current  software  development  methods 
are  not  adequate  to  ensure  their  reliability.  To  meet  this 
challenge,  automated  software  development  methods  must  be 
developed  which  will  increase  reliability  far  beyond  what  it 
is  today. 

Another  factor  in  the  need  for  automated  software 
development  methods  is  the  inability  of  most  customers  to 
precisely  state  their  needs  in  the  early  stages  of  a  system' s 
life-cycle.  This  emphasizes  the  need  for  getting  the  customer 
more  involved  in  the  early  stages  of  software  development,  and 
a  method  for  providing  the  customer  with  a  more  accurate 
feeling  about  what  the  software  system  will  do  when  it  is 
finished  as  early  as  possible.  To  do  this,  there  must  be  an 
easy  way  for  making  changes  to  software  systems  throughout  the 


1 


system  lifetime,  from  the  earliest  stages  of  conceptual  design 
through  system  retirement.  This,  in  turn,  means  that 
software  must  be  developed  with  evolution  in  mind. 

A.  SOFTWARE  MAINTENANCE 

Maintenance  can  be  defined  as  modification  to  a  software 
product  after  delivery  to  correct  faults,  improve  performance 
or  other  attributes,  or  adapt  it  to  a  changec.  environment. 
[Ref.  3]  This  mindset  about  maintenance  being  done  only  after 
the  system  is  delivered  is  the  traditional  notion,  and  it  is 
one  of  the  reasons  maintenance  is  so  hard.  Designers  using 
that  mentality  were  not  forced  to  design  their  code  in  a  way 
that  made  making  changes  easy.  According  to  [Ref.  3],  the 
average  system  in  use  in  1987  was  three  to  four  years  old  and 
consisted  of  approximately  55  separate  programs  and  23,000 
different  source  statements.  Maintenance  on  these  systems  is 
hard  because  most  of  them  were  not  well  documented,  when  they 
were  designed,  and  the  people  who  built  them  are  no  longer 
available  to  maintain  them.  This  means  that  a  massive  effort 
is  needed  to  figure  out  how  to  change  some  of  them.  A 
different  mindset  is  needed  from  the  first  stages  of 
conceptual  design. 

We  prefer  to  think  of  software  evolution  as  any 
modification  made  to  a  software  product  throughout  its  life- 
cycle.  Consequently,  software  should  be  designed  with 
evolution  as  a  primary  consideration.  Some  of  the  factors 
which  can  facilitate  evolution  are: 
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1.  Modularity  -  Modules  should  be  designed  to  be  as  self- 
sufficient  as  possible. 

2.  Readability  -  Structured  programming  techniques  should 
be  used  whenever  possible  to  compensate  for  a  wide  variety 
of  programming  styles . 

3.  Documentation  -  Design  decisions  as  well  as  code  should 
be  well  documented  and  the  documentation  should  be 
maintained  throughout  the  life  of  the  system. 

4.  Simplicity  -  Designs  should  be  made  as  simple  as 
possible.  The  more  complex  a  system  is,  the  harder  it 
becomes  to  understand. 

These  factors  are  not  sufficient  to  ensure  system 
maintainability,  but  they  are  necessary.  As  we  mentioned 
earlier,  software  systems  in  the  future  are  going  to  be  much 
larger  and  more  complex.  Traditional  methods  for  design  and 
maintenance  will  not  be  sufficient.  More  innovative  ways  to 
handle  these  problems  will  be  necessary. 

1 .  Model  for  Software  Manufacture 

Software  manufacture  can  be  defined  as  the  combining 
of  primitive  components  of  a  software  system,  through  a 
sequence  of  derivations,  into  one  or  more  software  products. 
It  is  software  manufacture  which  establishes  the  relationships 
between  the  components  of  a  software  system  and  the  primitives 
from  which  they  were  derived.  Within  the  software 

manufacturing  process,  one  of  the  most  difficult  problems 
involves  dealing  with  change. 

Changes  are  inevitable,  and  they  can  come  in  several 
different  ways.  They  can  be  "pre-planned",  as  there  may  not 
have  been  enough  cime  to  incorporate  all  of  the  proposed 
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capabilities  into  a  system  in  the  time  provided,  they  can  be 
"corrective",  if  a  bug  is  discovered  in  the  system,  or  they 
can  be  "opportunistic",  when  it  is  discovered  that  a  change 
can  easily  be  made  to  the  original  design  which  will  improve 
it  in  some  way.  When  changes  are  made,  problems  can  develop 
if  all  the  components  of  the  system  affected  by  the  change  are 
not  modified  to  deal  with  the  change.  As  systems  get  larg<  r 
and  more  sophisticated,  these  problems  are  amplified.  [Ref.  4] 

In  [Ref.  4],  a  model  is  presented  for  managing  the 
software  manufacturing  process.  It  is  designed  to  represent 
software  systems  at  a  very  low  level,  concentrating  on  what 
the  system  does  and  how  its  components  depend  on  one  another. 
The  model  has  two  parts,  the  configuration,  C,  and  a  set  of 
difference  predicates,  which  serve  to  insure  consistent  change 
incorporation . 

The  configuration,  consists  of  a  bipartite 
Directed  Acyclic  Graph  (DAG) ,  with  components1  in  one  set  and 
manufacturing  steps  in  the  other.  Manufacturing  steps  are 
non-concrete  derivations  and  processes  performed  on 
components.  ^  is  a  tuple  <  G,  E,  L  >  where  G  is  a  DAG,  E  is 
the  subset  of  £  which  contains  the  export  components  of  the 
system,  and  L  is  a  labeling  function  which  assigns  distinct 
labels  to  all  the  nodes  in  G. 

Components  in  this  model  are  software  components, 
development  tools,  etc.,  which  exist  in  the  manufacturing 
environment . 


This  is  a  fairly  good  model.  It  provides  an 
excellent  representation  of  historical  data,  which  is  useful 
for  managing  change  information.  A  problem  arises  when  two 
separate  versions  of  a  system  have  emerged  and  the  merging  of 
their  capabilities  is  desired.  It  also  does  not  provide  for 
the  propagation  of  changes  throughout  a  series  of  different 
versions  of  a  system.  Each  such  update  must  be  made 
individually.  Additionally,  the  graph  contains  too  many 
unnecessary  components.  A  much  simpler  model  which  solves 
some  of  these  problems  is  presented  in  the  next  section. 

2 .  Model  For  Software  Maintenance 

The  model  for  software  maintenance  contained  in 
[Ref.  5]  is  designed  to  provide  a  methodology  for  integrating 
information  about  software  maintenance  activities  and 
configuration  control.  This  model  assumes  the  following: 

1.  Management  controls  system  changes. 

2.  Actual  maintenance  is  performed  outside  the  central 
configuration  repository. 

3.  Products  of  the  configuration  are  derived  from  the 
repository  and  installed  at  the  production  site. 

4.  The  system  configuration  remains  consistent  at  all 
times . 

The  model  is  comprised  of  two  major  elements,  system 
components  and  maintenance  steps.  System  components  are 
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defined  as  immutable  and  non-re-derivable2  software  objects. 
Maintenance  steps  are  defined  as  activities  which  can  change 
the  configuration  of  the  system. 

The  configuration  is  modelled  as  a  bipartite  DAG 
G  of  components  (C  nodes)  and  maintenance  steps  (M  nodes) , 
connected  by  a  set  of  input  arcs,  I  and  a  set  of  output  arcs, 
0.  A  sample  configuration  is  shown  in  Figure  1.  Maintenance 
steps  are  labelled  M,,  where  q  is  the  number  of  the  step, 
using  simple  enumeration,  the  input  and  output  sets  of  M^  are 
labelled  1,^  and  0Mq,  respectively.  The  following  properties 
apply  to  maintenance  steps: 

1.  All  maintenance  steps  can  have  0  or  more  inputs,  no  more 

than  one  output.  VM,  |  I*  |  >  0  &  |  0„  |  <  1 

2.  A  maintenance  step  is  empty  if  and  only  if  it  has  no 

inputs  and  no  outputs.  |  I„  |  *  |  0„  I  =0 

3.  If  a  maintenance  step  has  at  least  one  input,  it  must 

have  an  output.  VM,  |  IM  |  *  0  |  Om  |  =1 

4.  A  component  cannot  be  in  the  input  and  output  sets  of 

the  same  maintenance  step.  c  E  —,(c  E  1,^) 

5.  No  one  component  can  be  the  output  of  two  different 
maintenance  steps.  Vmw  m:  E  M,  (3c  E  C  such  that 

(  (mA,  c)  E  O  &  (my  c)  E  0)  )  => 

6.  There  is  a  set  of  primitives  in  the  configuration  which 
are  not  outputs  of  any  maintenance  step. 

P  =  {c  E  C  |  *3  m  E  M  such  that  (m,  c)  E  0} 


2Non-re-derivable  objects  are  source  objects,  while  re- 
derivable  objects  are  those  objects  which  can  be  constructed 
by  applying  some  tool,  or  set  of  tools,  to  a  set  of  source 
objects . 


6 


7.  Let  D*  =  (I  U  O)'  be  the  reflexive  transitive  closure  of 
the  union  of  the  input  and  output  relations  1  and  0,  then: 

a.  One  component  depends  on  another  if  and  only  if  they 
share  an  edge  in  D*  or  they  are  both  primitive  components 
and  related  by  an  "is-component-of "  dependency. 

Cj  depends  on  c±  ( cL ,  c})  E  D*  v 

cir  c}  E  P  such  that  is-component-of  (c3,  cj 

b.  One  maintenance  step  depends  on  another  if  and  only  if 
they  share  an  edge  in  D*.  m}  depends  on  mL  (mL,  m^)  E  D* 

c.  Me  is  the  set  of  maintenance  steps  affected  by  a 

change  to  the  component  c.  Ma  =  {m  E  H  |  (c,  m)  E  D* 


sets  spec 

inf 

v2 

Figure  1.  Sample  Configuration  in  The  Model  for  Software 
Maintenance . 
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Maintenance  steps  can  be  in  one  of  five  possible 

states : 

1 .  Invoked  -  A  requirement  for  the  step  has  been 
identified,  and  is  under  analysis. 

2.  Pending  -  The  step  has  been  approved,  but  assets  have 
not  been  obligated  to  perform  the  step. 

3.  Implementing  -  The  work  is  under  way. 

4.  Completed  -  The  work  is  finished  and  the  output  has  been 
returned  to  the  central  repository. 

5.  Abandoned  -  The  work  was  stopped  before  completion  or 
the  step  was  never  approved.3 

If  a  maintenance  step  is  in  the  implementing  state, 
it  can  be  turned  back  to  the  pending  state,  however  all  work 
done  on  this  maintenance  step  is  lost  and  must  be  redone. 
This  is  impractical,  because  composite  maintenance  steps  can 
be  composed  of  many  smaller  maintenance  steps,  and  if  a  large 
majority  of  the  component  steps  are  completed  when  the 
composite  step  is  turned  back  to  the  pending  state,  all  of 
that  work  is  lost. 

An  atomic  maintenance  step  is  defined  as  a  single 
change  in  a  single  component,  its  primary  input.  A  component 

c:  is  a  direct  descendant  of  a  component  Ci  if  ci  €E  0,^  and  cA 

is  the  primary  input  of  M,,  or  the  primary  input  of  is  a 
direct  descendant  of  ct.  This  recursive  direct  descendance 
relationship  defines  evolution  genealogy  sub-graphs  of  G  as 

3A  maintenance  step  can  be  abandoned  at  any  time  in  the 
first  three  states.  Once  it  is  completed,  it  stays  in  the 
configuration  forever. 


trees  with  primary  inputs  and  their  direct  descendants.  The 
genealogy  trees  have  the  following  properties: 


1.  All  direct  descendants  of  a  component  c  belong  to  the 
genealogy  tree,  or  sub-tree,  which  has  c  as  its  root. 

2.  There  exists  a  unique  path  between  c  and  any  of  its 
direct  descendants. 

When  multiple  maintenance  steps  use  a  component  c  as 
their  primary  input,  then  parallel  genealogies  are  formed. 
The  outputs  of  these  parallel  genealogies  become  different 
versions  of  a  system  derived  from  a  common  base,  c.  One  of 
the  problems  with  this  model  is  that  it  provides  no  way  for 
these  different  versions  to  be  integrated  back  together  to 
capture  all  of  the  capabilities  of  both  genealogies  in  one 
component.  This  idea  provides  part  of  the  motivation  for  this 
thesis . 

B.  RAPID  PROTOTYPING 

Rapid  prototyping  is  intended  to  allow  the  user  to  get  a 
better  handle  on  exactly  what  his/her  requirements  are  early 
in  the  conceptual  design  phase  of  development.  It  involves 
the  use  of  automated  tools  to  rapidly  create  "a  concrete 
executable  model  of  selected  aspects  of  a  proposed 
system" [Ref.  6]  to  allow  the  user  to  view  the  model  and  make 
comments  early.  The  prototype  is  then  rapidly  reworked  and 
redemonstrated  to  the  user  over  several  iterations  until  the 
designer  and  the  user  have  a  precise  view  of  what  the  system 
should  do.  This  process  produces  a  validated  set  of 
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requirements  which  become  the  basis  for  designing  the  final 
product . [Ref .  6]  The  prototype  can  also  become  part  of  the 
final  product.  In  some  prototyping  methodologies,  the 
prototype  is  an  executable  shell  of  the  final  system, 
containing  only  a  subset  of  the  system's  ultimate 
functionality .  After  the  prototype  is  approved  by  the 
customer,  the  holes  are  filled  in  and  the  system  is  delivered. 
In  this  approach  to  rapid  prototyping,  software  systems  can  be 
delivered  incrementally  as  parts  of  the  system  become  fully 
operational. [Ref.  6]  Figure  2  shows  the  life-cycle  model  for 
this  prototyping  methodology. 

C.  COMPUTER  AIDED  PROTOTYPING  SYSTEM 

A  set  of  computer-aided  software  development  tools, 
called  the  Computer-Aided  Prototyping  System  or  CAPS  is  being 
developed  at  the  Naval  Postgraduate  School  to  support 
prototyping  of  embedded  hard  real-time  systems . [Ref .  6]  CAPS 
is  designed  to  reduce  the  amount  of  effort  required  by  the 
prototype  designer,  by  providing  an  integrated  set  of  tools, 
snown  in  Figure  3,  to  help  design,  translate  and  execute  the 
prototypes,  along  with  a  language  in  which  to  design  and 
program  the  prototypes. 

Computer-aided  software  development  tools  are  what  puts 
the  word  "rapid"  in  rapid  prototyping.  The  tools  provided  for 
in  CAPS  are  divided  into  three  categories: 
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Initial 

Goals 


Figure  2.  The  Prototyping  Life-Cycle  Model. 


1.  User  Interface 

2.  Software  Database  System 

3.  Execution  Support  System 

The  user  interface  contains  tools  that  support  the 
prototype  designer  in  designing  and  programming  prototypes. 
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the  software  database  system  provides  tools  which  search  the 
software  base  for  reusable  components,  retrieve  them,  and  make 
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them  ready  for  use  by  the  designer  in  a  prototype.  The 
execution  support  system  provides  tools  which  translate, 
schedule,  and  execute  the  prototype  for  the  designer.  The 
prototypes  are  written  in  a  language  designed  specifically  for 
CAPS,  called  PSDL. 

D.  PROTOTYPE  SYSTEM  DESCRIPTION  LANGUAGE 

PSDL  [Ref.  7]  is  the  design  based  language  written 
specifically  for  CAPS,  to  provide  the  designer  with  a  simple 
way  to  abstractly  specify  software  systems.  PSDL  places 
strong  emphasis  on  modularity,  simplicity,  reuse, 
adaptability,  abstraction,  and  requirements  tracing.  [Ref.  8] 

Modularity  is  supported  through  the  use  of  independent 
operators  which  can  only  gain  access  to  other  operators  when 
they  are  connected  via  data  streams.  Operators  can  represent 
either  functions  or  state  machines,  depending  on  whether  or 
not  they  have  state  variables.  Data  streams  can  be  one  of  two 
types,  data  flow  streams  or  sampled  streams.  Data  flow 
streams  operate  like  FIFO  queues  of  size  one.  Once  a  value  is 
placed  on  the  stream,  it  must  be  read  before  another  value  can 
be  placed  on  the  stream.  Sampled  streams  operate  like  memory 
cells  of  size  one.  A  value  is  on  the  stream  until  it  is 
replactd  by  another  value.  It  is  possible,  with  sampled 
streams,  that  some  values  could  be  read  more  than  once,  and 
some  may  never  be  read,  because  they  are  replaced  before  the 
stream  is  sampled. 


Simplicity  is  gained  through  the  use  of  a  small  number  of 
language  constructs  which  provide  powerful  capabilities  for 
designing  and  retrieving  prototypes.  The  grammar  for  the 
current  implementation  of  the  language,  located  in  Appendix  A, 
was  taken  from  [Ref.  9]  and  updated  with  changes  made  since 
the  publication  of  that  source. 

PSDL  prototypes  are  adaptable  through  the  use  of  control 
constraints.  constraints  can  be  placed  on  the  inputs  and 
outputs  of  operators,  as  well  as  timing  requirements. 
Reusable  software  components  can  be  modified  slightly,  when 
retrieved,  to  conform  to  these  constraints . [Ref .  8] 

Requirements  can  be  traced  in  prototypes  through  the  use 
of  description  constructs  which  can  be  written  to  reflect  the 
requirements  used  in  their  design. 

PSDL  programs  are  written  as  a  set  of  PSDL  operators  and 
data  types,  containing  zero  or  more  of  each.  PSDL  operators 
consist  of  a  specification  and  an  implementation.  The 
specification  defines  the  external  interfaces  of  the  operator 
through  a  series  of  interface  declarations,  provides  timing 
constraints,  and  describes  the  functionality  of  the  operator 
through  the  use  of  formal  and  informal  descriptions.  The 
implementation  can  either  be  in  PSDL  or  Ada.  Ada 
implementations  are  Ada  software  objects  which  provide  the 
functionality  required  by  the  operator  specification.  PSDL 
implementations  are  data  flow  diagrams  augmented  with  a  set  of 
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data  stream  definitions  and  a  set  of  control  constraints. 
PSDL  types  also  contain  a  specification  and  an  implementation. 

E.  CHANGE  PROPAGATION 

One  of  the  things  that  is  lacking  in  the  systems  we  have 
discussed  is  the  ability  to  automatically  propagate  changes 
through  multiple  versions  of  the  same  system.  This  notion 
becomes  important  when  a  fundamental  change  is  made  to  a  base 
system  from  which  multiple  different  versions  have  been 
created.  Rather  than  go  through  each  different  version 
individually  and  make  the  required  changes,  it  would  be  much 
more  efficient  to  make  the  change  to  the  base  version,  and 
then  merge  that  changed  base  with  each  of  the  different 
versions,  individually,  to  automatically  incorporate  the 
change  in  each  version.  This  notion  could  save  a  tremendous 
amount  of  time  and  effort  currently  spent  by  system 
maintainers  to  do  this.  An  example  of  this  idea  is  shown  in 
F igure  4 . 

Another  view  of  this  idea,  portrayed  in  Figure  5, 
addresses  the  problem  mentioned  in  the  discussion  of  the  Model 
for  Software  Maintenance,  regarding  re-combining  parallel 
genealogies.  If  two  different  modifications  of  a  base  program 
contain  useful  functionality,  then  automatically  integrating 
these  modifications  into  a  program  which  contains  the 
important  aspects  of  both  modifications  should  be  possible. 

This  thesis  is  directed  towards  developing  a  precisely 
defined  model  which  shows  how  this  can  be  accomplished  for 
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Figure  4 .  The  Notion  of  Change  Propagation  Represented 
Graphically . 


PSDL  programs.  In  Chapter  II,  we  review  some  work  previously 
done  on  merging  pure  extensions  and  integrating  modifications. 
In  Chapter  III,  we  take  the  ideas  described  in  Chapter  II  and 
adapt  them  to  PSDL  to  formulate  our  model. 
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Figure  5  .  The  Idea  of  Merging  Two  Different.  Versions  of  a  Base 
Program  into  a  Merged  Program  with  the  Significant 
Capabilities  of  Both  Versions  is  Similar  to  Propagating 
Changes . 
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II.  PREVIOUS  WORK 


This  chapter  explores  some  of  the  work  that  has  been  done 
by  other  researchers  in  this  area.  Section  A  discusses  work 
on  merging  software  extensions.  [Ref.  10]  Section  B  presents 
an  approach  to  integrating  non-interfering  software 
modifications.  [Ref.  11] 

A.  MERGING  SOFTWARE  EXTENSIONS 

1 .  Extension  vs .  Modification 

Program  extensions  are  additions  to  the  program 
which  extend  the  domain  of  the  partial  function  without 
altering  initially  defined  values.  Modifications  are 
additions  or  changes  which  do  alter  initially  defined  values. 
In  other  words,  program  extensions  add  functionality  to  the 
base  program  without  altering  the  already  existing 
functionality.  For  example,  consider  the  program  in  Figure  6. 
This  program  takes  two  real  numbers  as  input,  checks  to  see  if 
the  first  is  an  approximation  of  the  second,  and  prints  "True" 
if  the  difference  is  relatively  small  and  "False"  otherwise. 
This  program  can  fail  to  produce  an  output  for  some  inputs, 
namely  y  =  0.0.  It  can  easily  be  extended  by  adding  a  filter 
to  check  for  this  possibility,  as  shown  in  Figure  7. 

Program  modifications,  on  the  other  hand,  change  the 
original  functionality  of  the  program.  Program  Approx  2, 
shown  in  Figure  8  is  an  example  of  a  modification.  This 
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program  Approx ( input ,  output); 
const 

eps  :=  0.00001; 

var 

x,  y:  real; 

begin 

readln (x) ; 
readln (y) ; 

if  (abs((x  -  y) /y)  <  eps))  then 
writeln  ( "True" ) ; 

else 

writeln ("False") ; 

end. 


Figure  €.  Example:  Program  Approx  Diverges  if  y  =  0 . 


program  Approx_l (input ,  output); 
const 

eps  :=  0.00001; 

var 

x,  y:  real; 

begin 

readln (x) ; 
readln  (y) ; 
if  (y  <>  0)  then 

if  (abs((x  -  y)/y)  <  eps))  then 
writeln ( "True" ) 

else 

writeln  ("False") 

else 

if  (abs  (x  -  y)  <  0)  then 
writeln  ( "True" ) 

else 

writeln ( "False" ) 

end . 


Figure  7.  Example:  Program  Approx_l  is  a  Compatible  Extension 
of  Approx  Which  is  Defined  for  all  Inputs . 


program  computes  a  slightly  different  approximation  relation 
than  the  program  Approx.  Since  the  program  no  longer  provides 
the  original  functionality,  a  modification  has  occurred. 

More  formally,  using  an  approximation  ordering  C , 
if  p  is  a  base  program  and  p  C  q,  then  p  approximates  q  and 
q  is  an  extension  of  p.  That  is  to  say  that  q  agrees  with  p 
everywhere  p  is  defined,  and  q  may  be  defined  in  cases  wb  ire 
p  is  not.  [Ref.  10] 


program  Approx_2 ( input ,  output)/ 
const 

eps  :=  0.00001; 

var 

x,  y:  real; 

begin 

readln  (x) ; 
readln (y ) ; 

if  (abs ( (x  -  y) )  S  eps))  then 
writeln ( "True" ) ; 

else 

writeln  ( "False" ) ; 

end. 


Figure  8.  Example:  Program  Approx_2  Uses  a  Different 
Approximation  Method. 


With  this  ordering  in  mind,  two  specifications  p  and 
q  can  be  merged  by  finding  the  least  common  extension  of 
p  and  q,  written  p  U  q,  where  p  and  q  are  base  specifications 
and  p  U  q  is  the  merged  specification.  The  least  common 
extension  is  in  general  not  computable,  so  an  approximation  is 
used.  [Ref.  10] 
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2. 


Definitions 


In  [Ref-  10]/  only  four  domains  were  considered; 
specifications,  functions,  programs,  and  data  types.  These 
four  domains  are  defined  in  Figure  9.  All  domains  are  treated 
as  lattices.1  The  lattice  for  a  domain  representing  a  data 
type  D0  can  be  defined  as  the  set  D  =  D0  {  _L,  T  },  where  1 
approximates  everything  and  T  is  an  extension  of  everything. 
The  definition  of  the  extension  relation  for  D  is: 

x  C  y  <rr>  ( J_  S  x )  v  ( x  =  y )  v  ( y  =  T  )  2 


Specif i cat ion : 
Function : 
Program: 

Data  Type: 


Models  Intended  Behavior 

Implements  Actual  Behavior 

Algorithms  Defining  Partial 
Functions 

Set  on  which  Programs  Operate 


Figure  9 .  Definitions  of  Relevant  Domains . 


lattices  are  partially  ordered  sets  with  a  least  upper 
bound  and  a  greatest  lower  bound.  [Ref.  10] 

2The  strong  equality  relation  x  =  y  results  in  True  if  x 
and  y  are  the  same  element,  and  False  otherwise,  for  all 
elements  of  D  including  _L  and  T  . 
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In  merging  extensions,  X  represents  an  unsuccessful 
computation,  and  T  represents  the  results  of  combining 
incompatible3  data  values. 

In  [Ref.  10]  data  types  are  viewed  as  heterogeneous 
algebras,  where  each  primitive  operation  f  of  the  algebra  is 
extended  to  a  full  lattice  via  the  following  properties: 

1.  xt  =  X  f{x1,...,  xir  .  .  . ,  xn  )  =  X  and 

2.  (Xi  =  T  &  x3  %  X  for _1  <  j  <  n) 
f(xlf...,  xir  .  .  .,  xn)  =  T,  for  1  <  i  <  n. 

Property  1  says  that  for  any  element  xlf  if  xA  =  X 
then  any  operation  f  with  xt  as  a  parameter  returns  X. 
Property  2  says  for  any  xA  in  the  parameter  list  of  f,  if  xA 
=  F  and  no  x3  s  X  then  f  returns  T  .  Conditionals  for  this 
domain  are  extended  by  the  following: 

1.  (if  X  then  x  else  y)  ==  X 

2.  (if  T  then  x  else  y)  =  T. 

The  domains  for  functions  and  specifications  are 
defined  as  mappings  on  data  type  domains,  as  shown  in  Figure 
10.  Orderings  for  these  domains  are  defined  as  follows: 

1.  For  f,g  €:  Func,  f  Q  g  Vx  £  D[fr(x)  C  g(x)  ]  . 

2.  For  s,  t  G  Spec,  s  l  t  <J=^  Vx  G  D, 

y  G  R[s(x,y)  L  t (x, y) ]  . 


3An  unsuccessful  computation  includes  infinite 
computations,  and  computations  which  terminate  abnormally  or 
with  an  error  message. 
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Func  =  D  — >  R 

Spec  =  [D  x  R]  -4  Bool 

D,  R  are  Data  Type  Domains. 

D  — >  R  is  a  set  of  continuous  functions 
with  respect  to  C . 

Figure  10.  Domains  for  Functions  and  Specifications. 

The  limitation  to  continuous  functions  is  not 
considered  a  "serious  restriction",  as  all  computable 
functions  are  continuous.4  [Ref.  10] 


Dom:  Spec  =*  Powerset [  D  ], 

Dom(s)  =  {x  e  Dl  3  y  e  R  [True  C  s(x,y)]} 
Sat:  [Func  x  Spec]  —*  Bool, 

Sat(jf,  s)  «  V  x  €  Dom(s)  [True  C  s(x,Jf(x))] 


Figure  11.  Definitions  of  Domain  and  Satisfy. 

Since  specifications  which  leave  part  of  the  input 
space  unconstrained  are  of  interest,  the  definitions  shown  in 
Figure  11  are  provided  to  clarify  what  it  means  for  an  input 
value  to  be  in  the  domain  of  a  specification  and  for  a 
function  to  satisfy  a  specification.  The  domain  of  a 

4A  function  f  is  continuous  if  and  only  if  f  (Us)  =  Uf  (S)  , 
for  all  directed  sets  S.  S  is  directed  if  and  only  if  every 
finite  subset  of  S  has  an  upper  bound  in  S. 
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specification  is  that  set  of  input  values  for  which  an 
acceptable  response  can  be  provided,  thus  Dom(s)  is  the  set  of 
values  of  x  in  the  input  domain  D  for  which  there  exists  an 
output  value  y  in  the  output  domain  R  .  A  specification  for 
a  function  f  applied  to  a  pair  (x,  y)  will  yield  a  True  if  y 
is  an  acceptable  value  for  f  (x)  ,  False  if  not,  X  if  the 
specification  does  not  say  whether  y  is  acceptable,  or  T  if 
the  specification  is  inconsistent  with  respect  to  whether  y  is 
acceptable  or  not.  T  would  be  the  result  if  two  conflicting 
specifications  were  merged.  A  function  f  satisfies  a 
specification  s  if  and  only  if  for  every  value  x  in  the  domain 
of  s,  f  returns  a  value  which  is  acceptable.  Figure  12  shows 
an  example  used  in  [Ref.  10]  to  clarify  this  idea.  The 
specification  s  yields  X  if  x  <  0.  In  these  cases,  a  correct 
function  can  yield  any  value. 

s(x,y)  =  if  0  <  x  then  I  (y  -  x2)  I  <  £  else  X. 

Figure  12.  Example:  A  Specification  for  a  Square  Root 

Function . 

3 .  Program  Merging 

The  least  common  extension  of  two  functions  is  not 
computable  m  general.  [Ref.  10]  Since  the  least  common 
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extension  is  the  desired  result  of  a  merge  operation,  the 
theorem  shown  in  Figure  13  is  provided.5 


Theorem:  Correctness  of  Extensions 

If  s,  t  are  monotonic,  f  c  h,  g  C  h, 

Sat (f,  s) ,  and  Sat (g,  t)  then  Sat (h,  (s  U  t) ) . 


Figure  13.  Correctness  Theorem.  [Ref.  10] 

This  theorem  states  that  given  two  monotonic6 
specifications,  s  and  t,  and  three  functions,  f,  g  and  h,  if 
f  satisfies  s  and  g  satisfies  t,  then  any  common  extension  h 
of  f  and  g  satisfies  the  least  common  extension  of  s  and  t. 
The  function  h  is  an  approximation  for  the  least  common 
extension  of  f  and  g,  and  is  sufficient.  An  approximation  can 
yield  an  inconsistency  in  some  cases  where  consistent 
combinations  are  possible,  but  an  inconsistency  is  more 
acceptable  than  an  undefined  or  diverging  computation,  because 
it  can  be  detected  at  merge  time. 

A  program  consists  of  a  set  of  function  definitions 
accompanied  by  an  expression.  The  merging  of  two  such 


SA  proof  of  the  Correctness  Theorem  can  be  found 
in  [Ref .  10 ] . 

6A  function  f  is  monotonic  if  and  only  if 

X  C  y  =>  f  (x)  C  f  (y)  . 
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programs  will  result  in  a  third  program  containing  a  set  of 
functions  according  to  the  following  rules: 


1.  Functions  which  appear  in  one  of  the  input  programs 
and  not  in  the  other  will  appear  in  the  merged 
program  unchanged. 

2.  Functions  which  appear  in  both  of  the  input 
programs  with  the  same  number  of  parameters,  will  be 
merged. 

3.  Functions  which  appear  in  both  of  the  input  programs, 
but  with  a  different  number  of  parameters,  will  be 
merged.  The  formal  parameter  list  will  contain  a  T  at 
the  place  where  the  inconsistency  occurs. 

Expressions  are  merged  using  normal  forms.  [Ref.  10] 
uses  rewrite  rules  to  reduce  expressions  to  normal  forms.  For 
example,  consider  the  rewrite  rules: 

1  .  y  +  w  x 

2 .  z  '==$  w 

Using  these  rewrite  rules  on  the  expression 
(x  x  (y  +  z) )  reduces  it  to  the  expression  (x  x  x) .  Figure  14 
provides  an  example  of  their  use.  Normal  form  merging  can  be 
strengthened  if  axioms  and  theorems  about  the  data  structures 
are  added  to  the  rewrite  rules. 

Function  definitions  can  be  merged  using  normal 
forms  also.  Semantically  equivalent  function  calls  are  merged 
by  renaming  formal  parameters  in  one  input  version  to  match 
the  other  version,  if  necessary,  and  inserting  it  into  the 
merged  program.  Even  some  function  calls  with  the  same  number 
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(if  x  =  y+  w&  w=z  then  x  x  (y  +  z)  else  1) 


merged  with 

(if  x  =  y  +  w  &  w  —  z  then  x  x  (y  +  w)  else  0) 
yields 

(if  x=y+w&w=z  then  x  x  x  else  0) 

Figure  14.  Example:  A  Merge  Using  Rewrite  Rules. 


of  arguments,  but  not  semantically  equivalent  can  be 
consistently  merged  by  creating  a  new  function. 

The  work  done  in  [Ref.  10]  was  the  first  of  its  kind 
that  we  were  able  to  find.  It  provides  a  mathematical 
foundation  for  performing  program  merges,  and  shows  that 
merging  programs  is  possible.  The  next  section  builds  upon 
this  foundation,  and  provides  an  algorithm  for  merging  two 
modifications  of  a  base  program. 

B.  AN  ALGORITHM  FOR  INTEGRATING  PROGRAM  MODIFICATIONS 

Many  times  in  the  software  evolution  cycle,  base  programs 
are  altered  or  enhanced  in  different  ways  to  meet  the  needs  of 
different  customers.  This  leads  to  the  development  of 
parallel  genealogies,  as  described  in  Chapter  I.  At  a  later 
time  in  the  evolution  cycle,  a  customer  may  want  a  program 
which  has  all  the  capabilities  of  two  different  genealogies. 
This  leads  to  the  need  for  some  automated  way  of  integrating 
two  genealogies  into  a  single  working  program.  This  automated 
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integration  method  could  also  be  used  to  propagate  changes 
made  to  a  base  program  through  all  of  its  offspring.  This  is 
accomplished  by  making  the  change  to  the  base  program,  and 
then  integrating  that  changed  base  program  with  each  of  the 
offspring . 

In  [Ref.  11],  an  algorithm  is  presented  for  integrating 
two  non-interfering  modifications  of  a  base  program.  The 
integration  produces  a  third  program  which  reflects  both 
modifications.  This  integration  method  can  be  useful  in 
recombining  parallel  genealogies  as  illustrated  above.  The 
algorithm  uses  program  dependence  graphs  (PDGs)  to  abstractly 
represent  the  programs,  then  by  using  program  slicing, 
determines  which  portions  of  the  two  versions  are  different 
from  the  base  program.  Using  this  information,  the  algorithm 
determines  if  the  changes  interfere7  with  each  other.  If  they 
do  not  interfere,  the  different  program  slices  are  combined 
into  one  integrated  PDG,  which  is  then  transformed  into  the 
final  version  of  the  program. 

1 .  Program  Dependence  Graphs 

As  mentioned  earlier,  [Ref.  11]  uses  PDGs  to 
automate  the  merging  process.  A  PDG  for  a  program  P  is  a 
directed  graph,  Gp  with  several  kinds  of  vertices  connected  by 

’Versions  A  and  B  interfere  with  respect  to  a  Base 
program  if  3  an  initial  state  and  variable  x  such  that  A,  B, 
and  Base  all  compute  different  values  of  x. 


several  different  kinds  of  edges.  The  vertices  represent  one 
of  the  following: 


1.  The  Entry  Vertex 

2.  Initial  Definitions:  "x  :=  Init ial_State (x) " 

3.  Assignments 

4.  Control  Predicates 

5.  Final  Use  Statements:  "Final_Use (x) " 

Edges  represent  dependencies  between  vertices: 

1.  Control  Dependencies:  =>c 

2 .  Data  Dependencies : 

a.  Flow  Dependence:  =>f 

b.  Def-Order  Dependence:  =>do 

Control  dependence  edges,  v2  =>c  v2  are  contained  in 
Gp  if  and  only  if  one  of  the  following  properties  holds: 


1.  V;  is  an  entry  vertex  and  v2  represents  a  component  of 
P  not  subordinate  to  a  control  predicate.  This  type  of 
control  dependence  edge  is  always  labeled  True. 

2.  vx  is  a  control  predicate  and  v2  is  a  component 
immediately  subordinate  to  v2 . 

a.  If  Vj  is  a  while  predicate  and  v2  is  in  the  loop 
body,  the  edge  is  labeled  True. 

b.  If  vt  is  a  conditional  predicate,  the  edge  is 
labeled  True  if  v2  is  on  the  then  branch.  False  if 
v2  is  on  the  else  branch. 


Data  dependence  edges,  v,  =>  v2  indicate  that  v2  must 
occur  before  v2  for  data  to  be  valid.  Gp  contains  a  flow 

dependence  edge,  v2  =$f  v,  if  and  only  if: 
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1.  vx  defines  a  variable,  say  x. 

2.  v2  uses  x. 

3.  Control  can  reach  v2  after  v2  along  a  path  that 
doesn't  change  the  value  of  x. 

Flow  dependence  edges  due  to  a  particular  x  appear 
as  {=>/) .  Flow  dependencies  are  further  classified  as  loop 
carried  (=$lc)or  loc  )  independent  ( =S>2i)  .  v2  is  dependent  on  v2 
along  a  loop  independent  edge,  =S>2l  v2,  if  in  addition  to  a, 
b  and  c  above,  there  is  an  execution  path  that  satisfies  c  and 
does  not  include  a  backedge  to  the  predicate  of  the  loop  that 
encloses  v2  and  vx.  v2  is  dependent  on  v1  along  a  loop  carried 
edge  for  a  loop  L,  vx  =>ic(L)  v2,  if  in  addition  to  1,  2,  and  3 
above,  the  following  properties  also  hold: 

4.  There  is  an  execution  path  which  satisfies  3  and 
includes  a  backedge  to  the  predicate  L. 

5.  vx  and  v2  are  enclosed  in  loop  L. 

Def-order  edges,  vx  =>da  v2,  appear  in  G  if  and  only 
if  the  following  properties  hold: 

1.  v x  and  v2  are  both  assignments  to  the  same  variable  x. 

2.  Vj  and  v2  are  in  the  same  branch  of  every  conditional 
statement  that  encloses  them. 

3.  There  is  another  vertex  v3  that  reads  x  and  is 
dependent  on  both  vx  and  v2  along  flow  dependence  edges. 

4.  vx  occurs  before  v2 . 

Using  these  components,  a  program  dependence  graph 
can  be  constructed  for  any  program.  Figure  15  she  s  an 
example  of  a  simple  program  and  Figure  16  shows  its 


program  nada 

sum  : =  0; 
x  :=  1; 

while  x  <  11  do 

sum  :=  sum  +  x; 
x  :  =  x  +  1  ; 

end 

end(x,  sum) 


Figure  15.  Example:  A  Simple  Program  to  Illustrate  Program 
Dependence  Graphs . 


Figure  16.  Example:  The  Program  Dependence  Graph  for  the 

Program  nada . 


associated  PDG.  By  analyzing  parts  of  this  graph  which  affect 
a  certain  variable,  one  is  able  to  observe  the  effects  of  a 
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change  to  the  program  with  respect  to  that  variable.  This  is 
done  using  a  technique  known  as  program  slicing. 

2 .  Program  Slicing 

The  program  slice  of  a  graph  G  with  respect  to  a 
vertex  s  is  the  subgraph  of  G  containing  all  vertices  which 
can  reach  s  by  way  of  control  or  flow  dependence  edges,  along 
with  the  edges . 

V(G/s)  =  {w  e  V(G)  |  w  =>/  s } 

To  get  the  slice  of  a  graph  G  with  respect  to  one  of 
the  output  variables,  say  x,  merely  take  the  slice  with 
respect  to  the  vertex  labeled  "Final_Use (x) " .  Def-order  edges 
are  contained  in  the  slice  only  if  the  vertex  which  depends  on 
it  is  also  included  in  the  slice.  This  can  be  extended  to  a 
set  of  vertices  S  =  {slf  s2,  ...,  st)  by  taking  the  union  of 
the  vertex  sets  of  all  of  the  individual  program  slices. 
Figure  17  shows  an  example  of  slice  of  the  program  nada  taken 
with  respect  to  the  variable  x.  Figure  18  shows  the 
corresponding  PDG. 

3 .  Program  Semantics  and  Program  Dependence  Graphs 

The  problem  with  text  merging,  as  has  been  pointed 

out  several  times,  [Ref.  10,11]  is  that  it  discounts  the 
influence  of  semantics  on  program  structure.  In  merging 
programs,  the  semantics  must  be  merged  as  well.  PDGs  provide 
a  way  to  do  that. 
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program  nada_x 
x  :  =  1  / 

while  x  <  11  do 
x  :  =  x  +  1 

end 
end (x) 


Figure  17.  Example:  The  Slice  of  the  Program  nada  Taken  with 
Respect  to  x . 


Figure  18.  Example:  Program  Dependence  Graph  for  nada_x. 

It  can  be  said  that  two  programs  are  equivalent  if 
they  provide  the  same  results  for  all  possible  input  values. 
Two  programs  P  &  Q  are  strongly  equivalent,  if  and  only  if, 
for  all  possible  states  (7,  P  &  Q  both  diverge  when  initiated 
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at  o,  or  they  both  halt  with  the  same  final  values.  If  they 
are  not  strongly  equivalent,  then  they  are  not  equivalent. 


[Ref.  11]  provides  the  theorem  shown  in  Figure  19.  This 
theorem  states  that  if  two  PDGs  are  isomorphic  then  their 
representative  programs  are  semantically  equivalent.  The 
contrapositive  to  that  is  inequivalent  programs  have  non¬ 
isomorphic  PDGs. 

Theorem:  If  P,  Q  are  programs  such  that  Gp  is  isomorphic 
to  G0,  then  P  is  strongly  equivalent  to  Q. 


Figure  19.  Strong  Equivalence  Theorem. 


Another  theorem  stated  in  [Ref.  11]  is  the  Slicing 
Theorem  shown  in  Figure  20.  This  theorem  states  that  for  Q, 
a  slice  of  program  P,  P  &  Q  behave  equivalently  at  all  places 
which  are  common  to  both  P  &  Q. 


Theorem:  Let  Q  be  a  slice  of  program  P  with  respect  to  a 

set  of  vertices.  If  a  is  a  state  on  which  P  halts,  then 
for  any  state  o'  that  agrees  with  a  on  all  variables  for 
which  there  are  initial-definition  vertices  in  GQ: 

(1)  Q  halts  on  O'  . 

(2)  P  and  Q  compute  the  same  sequence  of 
values  at  each  program  point  of  Q. 

(3)  The  final  states  agree  on  all  variables 
for  which  there  are  final-use  vertices  in  Ga. 


Figure  20.  Slicing  Theorem. 
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4.  Determining  Behavior  Difference*  in  Variant* 

In  order  to  integrate  two  different  versions  of  a 
base  program,  their  differences  from  the  base  must  be 
determined.  This  can  be  done  using  the  PDGs  of  the  different 
versions.  This  model  assumes  that  only  changes  in  the 
behavior  of  a  modification  with  respect  to  its  base  are 
significant.  If  the  slice  of  GBASE  with  respect  to  a  vertex  v 
is  different  from  the  slice  of  GA,  where  A  is  the 
modification,  with  respect  to  v,  then  this  is  an  indication  of 
possible  changed  behavior.  All  such  vertices  where  GBASE  and 
GA  differ  are  called  the  affected  points  APa  BASE  of  GA.  The 
slice  Ga/APa  base  is  a  graph  which  captures  the  behavior  of  A 
that  is  different  from  the  BASE.  Determining  the  affected 
points  by  checking  the  program  slices  for  every  vertex  in  the 
graph  is  not  very  efficient.  [Ref.  11]  presents  a  function 
for  doing  this  that  requires  at  most  two  complete  examinations 
of  the  graph.  It  is  the  function  called  AffectedPoints [Ref . 
11,  P.  21],  and  is  based  on  the  following  three  observations: 

1.  All  vertices  in  GA  but  not  in  GBASE  are  affected  points. 

2.  Each  vertex  w  of  GA  with  a  different  set  of  incoming 
flow  or  control  edges  than  in  GBASE  gives  rise  to  a  set  of 
affected  points,  namely  the  vertices  which  can  be  reached 
via  zero  or  more  flow  or  control  edges  from  w. 

3.  Each  vertex  w  of  GA  with  an  incoming  def-order  edge, 
due  to  a  vertex  u  that  does  not  appear  in  GBASE,  gives  rise 
to  a  set  of  affected  points,  namely  the  vertices  that  can  be 
reached  via  zero  or  more  flow  or  control  edges  from  u. 
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5 .  Merging  Program  Dependence  Graphs 

Once  the  PDGs  have  been  created  for  the  different 
modifications  and  the  base,  and  all  the  differences  between 
the  modifications  and  the  base  have  been  determined,  the 
merged  PDG  GM  must  be  created.  GM  is  formed  by  taking  the 
union  of  the  slices  representing  the  changed  behaviors  of 
versions  A  and  B  with  respect  to  the  base  and  the  s  ice 
representing  the  preserved  behavior  of  the  base  in  both 
versions  A  and  B.  This  final  slice  contains  the  subset  of 
V(G8ASE)  for  which  the  slices  in  all  three  versions  are 
isomorphic,  and  is  represented  by  PPBxsc,a,b- 

1.  PPbase.a.b  =  €  V(Gbase)  |  <GBASE/v)  =  (GA/ v)  =  <G,/v)  ) 

2*  =  (Ga/APa  BASE)  (GB/APB  BASE)  (GBASE/PPBASC  A  B) 

6 .  Determining  Interference  Between  Modifications 

A  merged  PDG  created  as  described  above  can 
inaccurately  reflect  the  changed  behavior  of  the  two 
modifications  in  two  ways.  First,  the  union  of  two  feasible9 
PDGs  is  not  necessarily  a  feasible  PDG.  Secondly,  GM  may  not 
preserve  the  differences  in  the  behavior  of  the  modifications 
with  respect  to  the  base.  Interference  when  either  of  these 
conditions  occurs.  Testing  for  interference  due  to  the  first 
condition  is  done  during  the  program  reconstitution  process. 
A  theorem  is  provided  in  Reference  5  which  states  that  the 

®A  PDG  GP  is  feasible  if  it  is  a  PDG  for  a  program  P.  The 
slice  G/S  is  feasible  if  S  c  V (G)  and  G  is  feasible. 
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function  Reconst ituteProgram  will  succeed  if  and  only  if  G*,  is 
feasible.  Testing  for  interference  due  tc  th<=>  second 
condition  can  be  done  by  merely  checking  the  following 
condition : 

GM/APx>8ASe  =  Ga/APabase  and  GM/APB  BASE  =  Gb/APbbase 

7 .  Program  Reconstitution 

Program  reconstitution  is  accomplished  through  the 
use  of  a  function  called  Reconst ituteProgram .  This  function 
first  attempts  to  order  the  tree  created  by  the  control 
dependencies  between  the  vertices  using  the  flow  dependencies. 
It  then  transforms  the  graph  into  an  abstract  syntax  tree  from 
which  a  program  is  formed.  A  PDG  is  then  created  for  the 
program  created  and  is  checked  against  G„.  This  function  will 
fail  if  either  the  vertices  cannot  be  ordered  or  the  PDG  of 
the  created  program  is  not  isomorphic  to  GM. 

The  algorithm  Integrate  described  in  this  section  is 
far  from  perfect,  but  up  to  this  time,  seems  to  be  the  most 
complete  work  of  its  kind.  Portions  of  the  algorithm  still 
have  problems,  though.  One  example  is  that  the  ordering  of 
the  vertices  done  in  Step  5  of  the  algorithm  is  a  problem  that 
is  NP-Complete. 

C .  SUMMARY 

In  this  chapter,  we  have  explored  two  different 
approaches  to  the  software  integration  px'oblem.  In  Section  A, 
work  done  in  modelling  the  merging  of  pure  extensions  of  a 
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program  was  presented.  This  provided  a  sound  foundation  for 
understanding  the  work  done  in  Section  B.  Section  B  explored 
the  integration  of  non-interfering  versions  of  programs 
through  the  use  of  program  dependence  graphs  and  an  algorithm 
for  integrating  different  slices  of  the  graphs  for  different 
versions  into  a  merged  graph,  from  which  a  merged  program  can 
be  created.  These  two  bodies  of  work  have  helped 
significantly  with  our  understanding  of  the  complexities  of 
program  integration  and  the  development  of  a  model  to  account 
for  those  complexities. 
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III.  A  MODEL  FOR  MERGING  PSDL  PROGRAMS 


PSDL  programs  are  made  from  the  combination  of  one  or 
more  Abstract  Data  Types  and/or  Operators.  Since,  for  the 
current  implementation  of  PSDL,  all  Abstract  Data  Types  are 
implemented  in  Ada,  merging  them  is  not  within  the  scope  of 
this  thesis  and  is  not  included  in  our  model.  We  do  model  the 
merging  of  a  base  PSDL  operator,  Base,  with  two  modifications 
or  extensions,  A  and  B,  of  Base,  into  a  least  common 
extension,  M.  We  refer  to  this  three-way  merging  model  as 
"change-merging",  to  prevent  confusion  with  other  merging 
models.  This  chapter  defines  the  operations,  11,  U,  and  -, 

and  the  relation  C  as  they  pertain  to  change-merging  A,  Base 
and  B  into  M.  As  was  pointed  out  in  Chapter  2,  [Ref.  10] 
tells  us  that  the  least  common  extension  of  two  programs  is 
not  computable  in  the  general  case.  This  fact  is  also  true 
with  PSDL  programs.  We  will  show  that  an  approximation  to  the 
least  common  extension  is  enough  to  provide  a  successful 
change-merge  in  most  cases . 

The  relation  C  is  defined  as  the  approximation  relation 
for  the  lattice  created  by  combining  all  PSDL  operators 
together  with  a  T  and  a  1  as  shown  in  Figure  21.  If  Y  is  an 
extension  of  X,  then  we  say  X  approximates  Y,  written  X  C  Y . 
The  F,  or  top  element,  is  an  extension  of  all  possible  PSDL 


operators.  This  is  an  overconstrained  artificial  component 
which  represents  an  inconsistency .  The  -L,  or  bottom  element, 
is  an  approximation  of  all  possible  PSDL  operators.  This  is 
an  artificial  unconstrained  component  that  represents  an 
undefined  element.  Having  these  components  in  the  lattice 
provides  a  way  for  us  to  completely  define  a  change-merge 
operation  on  PSDL  operators.  If  T  is  the  result  of  a  change- 

merge  operation,  there  is  no  consistent  way  to  provide  a 
change-merge  that  is  syntactically  correct.  _L,  on  the  other 
hand,  is  a  component  that  is  an  undefined  (i.e.  an 
unimplemented  or  non-terminating  program) . 

The  difference  between  two  PSDL  operators,  A  -  B,  gives 
the  behavior  found  in  A  and  not  in  B.  Any  functionality  which 
is  common  to  both  operators  is  not  included  in  A  -  B.  The 
greatest  common  approximation  of  two  PSDL  operators,  A  and  B, 
is  written  A  LI  B.  The  greatest  common  approximation  of  three 
operators,  A  H  Base  FI  B  gives  us  the  behavior  which  is  common 
to  all  three  operators. 

To  get  the  desired  behavior  of  M  we  must  combine  this 
common  behavior,  A  (1  Base  L!  B,  with  the  difference  between 

the  behavior  of  Base  and  each  of  the  two  modifications  or 
extensions,  A  -  Base  and  B  -  Base.  From  this  we  can  conclude 
that  change-merging  the  three  versions  can  be  done  using  the 
following  formula: 

M  =  A[Base]B  =  (A  fi  Base  LI  B)  LJ  A  -  Base  U  B  -  Base. 
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Figure  21. 


The  Set  of  All  PSDL  Operators  Forms  a  Lattice . 


It  turns  out  that  it  is  not  necessary  to  use  the  greatest 
common  approximation  of  all  three  operators.  The  difference 
between  A  H  B  and  A  ("1  Base  fl  B  is  contained  in  the 

modifications  A  -  Base  and  B  -  Base,  as  shown  by  the  following 
equations  and  inequalities: 

(A  D  B)  ~  (A  fl  Base  H  B)  =  (A  fl  B)  -  Base  = 

(A  -  Base)  fl  (B  -  Base)  C 
(A  -  Base)  U  (B  -  Base) 

Thus  in  merging  the  three  versions,  it  is  sufficient  to 
merge  the  greatest  common  approximation  of  A  and  B  with  the 
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behavior  differences  between  the  two  modifications  and  the 


Base,  as  shown  in  the  following: 

M  =  A  [Base]  B  =  (A  f!  B)  Li  (A  -  Base)  U  (B  -  Base)  . 

This  chapter  defines  what  this  equation  means  in  change¬ 
merging  the  different  components  of  a  PSDL  operator. 

PSDL  operators  consist  of  two  major  parts:  a 
specification  and  an  implementation.1  The  specification  of 
an  operator  A,  denoted  SA2,  defines  the  external  interfaces  of 
the  operator  and  identifies  its  functionality  through  the  use 
of  text  descriptions  and  keywords.  The  change-merging  of  two 
PSDL  specifications  is  discussed  in  Section  A.  The 

implementation  part  of  an  operator  A  provides  an  Enhanced  Data 
Flow  Diagram  consisting  of  a  data  flow  diagram,  a  set  of 
internal  data  streams,  and  a  set  of  constraints  which  control 
the  internal  operations  of  the  operator.  For  this  model,  we 
separate  the  implementation  part  of  the  operator  into  two 
separate  and  distinct  problems.  The  first  is  change-merging 
two  simple  data  flow  diagrams,  denoted  DA  and  D„,  discussed  in 
Section  B,  and  the  second  is  the  integration  of  two  sets  of 
internal  data  streams,  denoted  DSA  and  DSB,  and  control 
constraints,  denoted  CA  and  CB,  discussed  in  Section  C. 


xThe  change-merging  of  specifications  and  implementations 
is  different,  so  we  handle  it  separately. 

2In  our  model,  the  subscript  of  a  set  signifies  which 
operator  it  represents. 
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A.  SPECIFICATIONS 

The  specification  of  a  PSDL  operator,  A,  tells  the  rest 
of  the  program  what  the  operator  does.  Changes  to  the 
specification  of  an  operator  ptoentially  affect  all  of  the 
other  parts  of  the  program  where  the  operator  is  used.  We 
assume  the  author  of  a  change  to  an  operator  specification  has 
also  made  the  necessary  changes  in  all  of  the  contexts  where 
the  operator  is  used.  For  this  reason,  change-merging 
operations  must  be  applied  to  entire  prototypes.  However, 
changes  to  entire  programs  are  merged  by  merging  changes  to 
corresponding  sub-components.  This  section  focuses  on  the 
change-merge  operation  for  the  specification  of  each  sub¬ 
component  . 

1 .  Interfaces 

The  interface  of  a  PSDL  operator  is  the  definition 
of  the  operator's  external  contacts.  It  contains  the  input 
set  expected  by  the  program,  IA,  the  output  set  that  can  be 
expected,  0A,  and  the  set  of  generic  parameters  that  may  be 
instantiated,  GNA.  IA,  0A,  and  GNA  are  all  ordered  sets.  It 
also  contains  a  set  of  internal  state  variables,  StA,  a  set  of 
possible  exceptions,  EA,  and  a  set  of  timing  requirements  that 
are  met  by  the  program,  TA.  StA,  EA,  and  TA  are  all  unordered 
sets . 

a.  Ordered  Seta 

Ordered  sets  are  a  significant  building  block 
for  many  programming  languages,  including  PSDL.  For  the 
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purpose  of  change-merge  operations,  ordered  sets  should  be 
modelled  using  a  flat  lattice,  as  shown  in  Figure  22.  When 
the  order  of  a  set  is  significant,  then  any  change  made  to  the 
set  is  an  incompatible  change  and  creates  a  set  which  is 
neither  an  approximation  nor  an  extension  of  the  original  set. 
This  means  that  the  only  set  which  is  an  approximation  for  the 
order*  i  set  is  the  undefined  set,  signified  by  the  X  in  Figure 
22,  and  the  only  set  which  is  a  compatible  extension  of  the 
ordered  set  is  the  overconstrained  set  signified  by  the  T  in 

Figure  22.  The  applications  of  this  structure  to  PSDL 
specifications  are  explained  next. 


Figure  22.  Ordered  Seta  Have  a  Flat  Lattice  Structure. 


(1)  Input  and  Output3 

Input  and  Output  interfaces  are  sets  of 
input  and  output  streams.  The  order  of  these  sets  is 
significant  because  actual  parameters  are  associated  with 
formal  parameters  based  on  the  order  in  which  they  appear.  In 
change-merging  Ix,  I8  and  1*.,,  into  IM,  any  change  between  the 
interface  set  of  Base  and  the  two  modified  versions  is 
significant,  and  must  be  preserved  in  the  change-merged 
version.  The  change-merged  set  of  inputs,  or  outputs,  is 
determined  by  the  following  rule: 

iM  =  *  (i*  -  i. ...)  U  <ix  n  IB)  LI  <IB  -  IB„.) 

Based  on  this  rule,  one  of  the  following 
three  situations  can  occur: 

1.  If  both  of  the  modifications  have  the  same  interface 

set  as  the  base,  then:  IM  =  JL  U  IBa„  U  I  =  IB.„. 

2.  If  one  of  the  two  modifications,  say  Ix  is  the  same 
as  the  base,  and  the  other  is  not,  then: 

iH  =  i  U  i  Ll  iB  =  iB. 

3.  If  both  of  the  modifications  are  different  from  the 

base  version,  then:  IH  =  IA  U  i  U  I8  =  T. 

The  first  situation  is  the  case  in  which 
no  changes  were  made  between  the  inputs  of  the  Base  and  the 
two  modifications.  In  this  case,  the  change-merged  version 


3The  change-merging  of  input  and  output  sets  is 
identical,  so  only  the  change-merging  of  input  sets  is  shown 
here . 
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should  have  all  of  the  same  inputs,  or  outputs.  The  second 
situation  is  the  case  in  which  only  one  of  the  modifications 
changed  from  the  base.  In  this  case,  the  change  from  the  base 
is  significant  and  must  be  preserved  in  the  change-merged 
version.  The  third  situation  is  the  case  where  both  of  the 
modifications  changed  from  the  base.  The  result  is  a  conflict 
because  there  is  no  proper  PSDL  specification  that  is 
consistent  with  both  modifications. 

An  example  of  an  interface  change-merge  is 

shown  in  Figure  23.  In  this  example,  I*  t-  IB.„,  but  IB  =  IB«..f 
so  IM  =  IA.  0Ba„  ^  0A  ^  Ob'  so  =  T . 


SB„.  =  INPUT 

x:  integer 
y:  real 
OUTPUT 

w:  integer 
z:  string 

SB  =  INPUT 

x:  integer 
y:  real 
OUTPUT 

w:  integer 


SA  =  INPUT 

x:  integer 
OUTPUT 

w:  integer 
t :  integer 
z :  string 


Sh  = 


INPUT 

x:  integer 
OUTPUT 

T 


Figure  23.  Example:  An  Interface  Merge. 
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(2)  Generic  Parameters 


The  Generic  interface  is  contained  only  in 
template  operators.  Template  operators  are  operators  in  the 
Software  Base  used  to  instantiate  software  components. 
Change-merging  generic  parameters  is  similar  to  change-merging 
input  and  output  parameters  with  the  exception  that  in 
addition  to  value  parameters,  generic  parameter  sets  may  also 
contain  operator  parameters  and  type  parameters.  Changes  to 
generic  sets  will  follow  the  same  rules  as  Input  and  Output 
sets.  Figure  24  shows  an  example  of  a  change-merge  operation 
on  generic  parameters. 

b.  Unordered  Seta 

Unordered  sets  are  modelled  using  a  "Powerset 
Lattice"4,  as  shown  in  Figure  25.  Because  unordered  sets  are 
modelled  using  this  type  of  lattice,  more  freedom  can  be 
exercised  in  change-merging  them.  Change-merge  operations  do 
not  follow  the  same  rules  for  these  unordered  sets  as  for 
ordered  sets. 

(1)  States 

State  variables  differ  from  input  and 
output  variables  in  that,  abstractly,  they  are  tuples, 
containing  a  name,  a  type  and  an  initial  value.  As  the  set  of 
state  variables  is  unordered  and  invisible  to  the  rest  of  the 
program,  the  state  set  can  be  increased  or  decreased  without 

4A  "Powerset  Lattice"  is  a  lattice  whose  ordering  is 
based  the  powersets  of  a  given  data  type.  A  is  a  compatible 
extension  of  B,  if  A  is  a  subset  of  B. 


GNB.„  =  GENERIC 

tl:  type, 
t2:  type, 

ol :  operat ion [ il , i2 : tl , ol : t2 ] , 
vl :  integer 

GNk  =  GENERIC 

tl:  type, 
t3:  type, 

o2:  operation [ il : tl , ol : t3 ] , 
vl :  integer 

GNb  =  GENERIC 

tl:  type, 
t2:  type, 

ol:  operation [il , i2 :tl , ol : t2 ] , 
vl :  integer 

GNm  =  GENERIC 

tl:  type 

t3:  type 

t4:  type 

o2 [il : t 1 , ol : t3 ] , 

vl :  integer 


Figure  24.  Example :  A  Merge  of  Generic  Parameters . 


affecting  other  parts  of  the  program.  In  change-merging  state 
variable  sets,  the  operations  [1,  U,  and  -  are  equivalent  to 
the  corresponding  set  operations,  kJ,  O  and  The  third  part 
of  the  tuple,  the  initial  value,  requires  an  additional  check 
in  the  change-merging  process.  These  initial  values  are 
ordered  using  a  flat  lattice,  because  they  are  ordinary  data 
values.  The  initial  value  of  a  change-merged  state  variable 
follows  the  same  change-merging  rules  as  input  and  output 
variables.  If  all  three  versions  have  different  initial 
values  for  the  same  state  variable,  then  the  change-merged 
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{a,  b,  cj 


U 

Figure  25 .  Unordered  Sets  Have  a  Powerset  Lattice  Structure . 


version  will  contain  a  T  in  the  place  where  the  initial  value 
is  assigned.  If  only  one  of  the  modifications  assigns  a 
different  initial  value  than  the  base  version,  then  the 
change-merged  version  will  contain  the  initial  value  of  the 
one  that  was  different.  Figure  26  shows  an  example  of  change¬ 
merging  state  variable  interfaces.  In  this  example,  the  state 
variable  s  is  assigned  a  value  in  Base  which  is  changed  by 
version  A,  but  not  B. 

(2)  Exceptions 

The  exceptions  interface  is  a  list  of 
identifiers  which  denote  exception  values  which  may  be 
returned  by  the  operator.  Consequently  U,  fl,  and  -  can  be 
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8«*»  — 

STATES 

s:  integer  initially  0 
t:  real  initially  30.0 


StA  = 

STATES 

r:  natural  initially  10 
s:  integer  initially  5 
t:  real  initially  10.0 


St,  = 

STATES 

p:  integer  initially  0 
s:  integer  initially  0 
t:  real  initially  20.0 


0 

10 


StM  = 

STATES 

p:  integer  initially 
r:  natural  initially 
s:  integer  initially  5 
t:  real  initially  T 


Figure  26.  Example:  A  Merge  of  State  Variable  Interfaces. 


interpreted  as  the  corresponding  set  operations,  tJ,  O, 
Exceptions  which  appear  in  one  or  both  of  the  modified 
versions,  and  not  in  the  base,  will  appear  in  the  change- 
merged  program.  Exceptions  which  appear  in  the  base  and  do 
not  appear  in  at  least  one  of  the  modifications  will  not 
appear  in  the  change-merged  program.  The  following  formula 
defines  the  exception  set  of  the  change-merged  program,  EM: 

em  =  [ea  n  eb]  u  [ea  -  eb..j  u  [eb  -  eb..j 

The  expression  Ea  Eb  yields  the  set  of 
exceptions  which  are  common  to  all  three  versions.  The 
expression  EA  -  EBm.  yields  the  set  of  exceptions  which  are  in 
modification  A  and  not  in  the  base.  The  expression  EB  -  Eb„„ 
yields  the  set  of  exceptions  which  are  in  modification  B  and 
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not  in  the  base.  These  sets  are  added  together  to  form  EM. 
An  example  of  a  change-merge  on  exception  sets  is  found  in 
Figure  27 . 


Eb„.  =  EXCEPTIONS 

EXCEPT I ONI , 
EXCEPTI0N2 , 
EXCEPTION3 


Ea  =  EXCEPTIONS 

EXCEPTI0N1 , 
EXCEPTION2 , 
EXCEPTIONS 


Eb  =  EXCEPTIONS 

EXCEPTI0N1 , 
EXCEPTION3 , 
EXCEPTION4 


EM  =  EXCEPTIONS 

EXCEPTION1, 
EXCEPTION4 , 
EXCEPTIONS 


Figure  27.  Example:  Merging  Exception  Sets. 


(3)  Timing  Information 

There  are  three  different  types  of  timing 
information  found  in  specifications  of  PSDL  operators,  Maximum 
Execution  Time (MET) ,  Maximum  Response  Time (MRT) ,  and  Minimum 
Calling  Period  (MCP)  .  MET  is  the  maximum  CPU  time  that  an 
operator  can  use  to  perform  its  assigned  task.  MRT  is  the 
maximum  amount  of  real  time  between  the  arrival  of  an  input 
value  on  the  input  stream  and  the  placement  of  an  output  value 
on  the  output  stream.  MCP  is  the  minimum  amount  of  time 
between  invocations  of  an  operator. 
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Change-merging  MET,  MRT  and  MCP  timing 
information  is  done  in  much  the  same  way  as  state  variable 
definitions.  If  the  timing  information  is  unchanged  in  both 
modifications  from  the  base,  then  it  will  remain  the  same  in 
the  change-merged  version.  If  it  is  the  same  in  one  of  the 
modifications  as  the  base,  but  different  in  the  other,  then 
the  changed  value  will  be  the  value  assigned  to  the  change- 
merged  version.  If  all  three  versions  contain  a  different 
timing  value,  then  the  change-merged  version  will  contain  a 
timing  value  of  T.  Examples  are  shown  in  Figure  28. 


MET  20  [  MET  20  J  MET  20  =  MET  20 
MCP  40  [  MCP  40  ]  MCP  30  =  MCP  30 
MRT  10  [  MRT  20  ]  MRT  30  =  MRT  T 

Figure  28.  Examples :  Merging  Timing  Information. 

2 .  Functionality 

The  functionality  of  an  operator  specification  is 
what  differentiates  it  from  other  operators.  Through  the  use 
of  keywords,  the  operator  can  be  distinguished  from  other 
operators  in  the  database  during  the  retrieval  process.  Text 
descriptions  are  provided  for  use  by  the  engineer.  Axiomatic 
descriptions  are  provided  to  allow  expert  system  techniques  to 
be  used  in  the  retrieval  process. 
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a .  Keywords 

The  keywords  section  of  an  operator 
specification  is  a  set  of  distinguishable  words  which 
explicitly  identifies  the  functionality  of  the  operator.  The 
order  of  these  words  is  not  significant.  The  change-merging 
of  the  set  of  keywords  is  done  in  the  same  way  as  the  set  of 
exceptions . 

b.  Informal  Description 

The  informal  description  of  a  PSDL  operator  is 
a  textual  explanation  of  the  functionality  of  the  operator. 
It  has  no  formalized  sub-structure,  therefore,  the  accurate 
change-merging  of  textual  explanations,  is  not  within  the 
scope  of  this  thesis.  It  is  assumed  that  accurate  change¬ 
merging  of  the  informal  description  will  be  done  by  the 
engineer  overlooking  the  change-merge  operation. 

c.  Formal  Description 

The  formal  description  of  the  PSDL  operator 
provides  an  axiomatic  representation  of  the  functionality  of 
the  operator.  Mathematical  properties  can  potentially  be 
automatically  change-merged  using  currently  available 
technology,  but  as  this  portion  of  the  language  has  not  yet 
been  determined  in  detail,  it  is  impossible  for  us  to  provide 
a  method  at  this  time. 

B.  DATA  FLOW  DIAGRAMS 

A  PSDL  Data  Flow  Diagram,  for  an  operator  A,  is  a  graph 
Da  =  {O,  L},  where  O  is  a  set  of  vertices  which  represent  the 
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component  operators  of  A,  including  the  constant  operator  EXT 
representing  external  contacts,  and  where  L  is  a  set  of 
links (labelled  edges)  which  represent  the  data  streams 
entering  and  leaving  the  elements  of  0.  The  labels  for  the 
links  are  the  names  of  the  data  streams  they  represent. 

Between  any  two  vertices,  o2  and  o2,  there  is  an  edge  for 
each  data  st  earn,  x,  that  is  an  output  of  oa  and  an  input  for 
o2 .  A  data  flow  diagram  can  have  parallel  edges,  since 
operators  can  have  multiple  outputs  and/or  multiple  inputs. 
Figure  29  shows  three  examples  of  PSDL  Data  Flow  Diagrams: 

1.  An  operator  with  no  inputs  or  outputs. 

2.  An  operator  with  one  input  and  one  output. 

3.  A  composite  operator  with  multiple  data  streams  between 

its  two  component  operators  and  multiple  output  streams. 

We  define  the  change-merging  operations  on  PSDL  data  flow 
diagrams  in  terms  of  a  bipartite  graph  Bx  =  (V,  S,  LI,  LO}  , 
where  V  is  the  set  of  operators  in  D*,  S  is  a  set  of  vertices 
which  represent  the  data  streams  of  operator  A,  LI  is  a  set  of 
edges  from  a  stream  vertex  to  an  operator  vertex,  representing 
input  links,  and  LO  is  a  set  of  edges  from  an  operator  vertex 
to  a  stream  vertex,  representing  output  links.  According  to 
this  model,  the  data  flow  diagrams  in  Figure  2  9  have  the 
following  bipartite  graph  representations: 
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Figure  29.  Example:  PSDL  Operator  Data  Flow  Diagrams 


1.  G.V  =  {A, EXT} 

G.S  =  {} 

G.LI  =  {} 

G . LO  =  { } 

2.  G.V  =  { B, EXT } 

G.S  =  { a, b} 

G.LI  =  {  (a,  B)  , (b, EXT) } 

G.LO  =  {  (EXT, a)  ,  (B,b)  } 

3 .  G.V  =  {C, D, EXT} 

G.S  =  {x, j,k,y, z} 

G.LI  =  {  (x, C)  ,  ( j , D)  ,  (k, D)  ,  (y , EXT)  ,  (z,EXT)  } 
G.LO  =  {  (EXT ,  x)  ,  (C,  j)  ,  (C,k)  ,  (D,y)  ,  (D,  z)  } 


Figure  30  gives  graphical  illustrations  of  these 
bipartite  graphs. 

The  bipartite  graph  models  have  no  edges  which  link  an 
operator  vertex  with  another  operator  vertex,  or  a  stream 
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vertex  with  another  stream  vertex.  For  each  input  to  an 
operator  vertex,  vlr  there  is  an  edge  in  LI  which  flows  from 
a  stream  vertex  sx.  For  each  output  from  an  operator  vertex 
v,,  there  is  an  edge  in  LO  which  flows  to  a  stream  s2. 

Change-merging  the  data  flow  diagrams  is  done  by  change¬ 
merging  the  graphs  G,.,.,  GA  and  G,  by  subsets  V,  S,  LI  and  LO. 
The  operations  U ,  11,  and  -  can  be  interpreted  as  the 
corresponding  operations  'U ,  D,  and  -.  The  following  equation 
defines  the  way  this  change-merge  is  accomplished: 

G*  =  (GA  -  gb..j  Lj  [Ga  n  Gb]  u  [Gb  -  gb..j 
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The  greatest  common  approximation  is  obtained  for  the 
Base  and  the  two  modifications  by  taking  the  intersection  on 
all  components  of  the  graph.  Then  these  common  components  are 
added  to  the  disjoint  components  of  each  modification  by 
subtracting  out  the  parts  of  the  two  modifications  which  are 
also  in  the  base.  This  operation  preserves  the  functionality 
common  to  all  the  versions,  while  ensuring  that  significant 
changes  made  by  the  two  modifications  are  included  in  the 
change-merged  graph.  An  example  of  change-merging  operations 
on  bipartite  graphs  is  shown  in  Figure  31,  and  illustrated 
graphically  in  Figure  32. 


Base . V  =  {A, EXT} 

Base.S  =  {x,y} 

Base. LI  =  { (x, A) , (y , EXT) } 
Base.LO  =  { (EXT, x) , (A, y) } 


A . V  =  (A, A1 , EXT } 

A. S  =  {x, y } 

A. LI  =  { (x, A) , ( x , A1 ) , 
(x, y,EXT) } 

A.LO  =  { (EXT , x) , (A, y ) 
(Al,  y)  } 


B.V  =  { A, B, EXT } 

B. 3  =  {x, y, t } 

B.LI  =  { (x, A) , (y,B) , 

(t ,  EXT)  } 

B.LO  =  { (EXT, x) , (A, y ) , 
(B ,  t )  } 


M.V  =  {A, Al , B , EXT } 

M.S  =  { x, y , t } 

H.LI  =  {  (x , A) ,  (x , Al ) ,  (y,B)  ,  (t , EXT)  } 
M.LO  =  {  (EXT , x) ,  (A, y )  ,  (Al,y)  ,  (B, t)  } 


Figure  31.  Example :  Merge  Operation  on  Data  Flow  Diagrams. 

In  this  example,  the  change-merged  set  of  operator 
vertices  is  obtained  by  adding  together  the  operator  vertices 
which  are  common  to  all  three  versions  with  the  operator 
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Figure  32.  Graphical  Illustrations  for  the  Merging  Operation 


in  Figure  31. 


vertices  which  are  particular  to  the  modifications.  The  sets 
of  stream  vertices  and  the  sets  o f  edges  are  treated 
similarly . 
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C.  DATA  STREAMS  AND  CONTROL  CONSTRAINTS 
1 .  Data  Streams 

A  set  of  data  stream  definitions,  DSA  defines 
variables  which  exist  internally  to  the  operator,  A,  and  are 
not  defined  in  the  specification.  The  order  in  which  the 
declarations  appear  is  not  significant.  They  have  the  same 
structure  as  exception  declarations,  and  can  be  change-merged 
using  the  same  rules.  If  a  stream  appears  in  DSBa>,,  then  it 
appears  in  DSM  if  and  only  if  it  appears  in  both  DSA  and  DSB. 
If  a  stream  does  not  appear  in  DSBa,.,  then  it  appears  in  D3M  if 
and  only  if  it  appears  in  at  least  one  of  the  sets  D3A  and  D3a. 


1 . 

X 

€ 

DS 

Bmtm  A  X  E  DSa  A  X  E 

dsb  => 

X 

€  dsm  . 

2  . 

X 

E 

DS 

B...  A  ~~*(x  E  DSa  a  X 

e  D3b) 

=>  ->{x  E  DSh)  . 

3. 

— 1 

(X 

E 

D£>b»««)  a  (x  E  DSa  v 

X  E  DSg 

) 

==>  x  E  DS„. 

4  . 

-> 

(X 

E 

ds8„j  a  “Mx  E  dsa 

v  X  E  DSg'. 

)  =>  “'(X  E  DS„) 

2 .  Control  Constraint* 

Control  constraints  are  a  set  of  pre-conditions 
which  control  the  firing  of  particular  components,  and  post¬ 
conditions  which  determine  the  output  provided  by  those 
components.  The  control  constraints  appear  in  the  change- 
merged  operator  according  to  the  same  rules  as  the  data  stream 
definitions.  Any  control  constraint  which  appears  in  all 
three  input  versions  in  the  exact  same  way  will  appear  in  the 
change-merged  operator  without  change.  Any  operator  which 
appears  in  one  or  both  of  the  modifications,  but  not  in  the 
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base,  will  appear  unchanged  as  long  as  the  conditions  of  the 
constraint  are  the  same.  Changes  in  conditions  are  handled 
differently  depending  on  the  type  of  constraint.  Input  and 
output  guards,  and  conditional  exceptions,  "TRIGGERED  IF", 
"OUTPUT  IF",  "EXCEPTION  IF",  and  timer  operations  have  logical 
predicates  as  conditions.  Timer  operations  are  not  change- 
merged  as  straight-forwardly  as  other  predicate  c  nstraints. 
Different  operations  exist  for  different  activities.  Start, 
stop,  read,  and  reset  are  the  four  timer  operations  used  in 
PSDL.  The  read  operation  has  no  effect  on  the  state  of  the 
timer,  so  these  operations  can  be  merged  independently.  If  a 
read  operation  appears  in  all  three  versions,  or  appears  in  at 
least  one  of  the  modif cat ions ,  but  not  in  the  base,  then  it 
appears  in  the  change-merged  version  as  well.  The  other  timer 
operations  do  affect  the  state  of  the  timer.  The  start  and 
stop  operations  affect  the  run  state  of  the  timer,  and  the 
reset  operation  affects  the  value  state  of  the  timer.  The 
reset  operation  is  thus  independent  of  the  others,  and  hence 
cna  be  merged  according  to  the  same  rules  as  the  read 
operation.  The  start  and  stop  operations  must  be  change- 
merged  using  a  flat  lattice  ordering  relation,  as  with  inputs 
and  outputs.  This  lattice  is  3hown  in  Figure  33.  The 
predicates  which  accompany  the  control  constraints  are  change- 
merged  according  to  the  usual  rule,  A[Base)B  =  (A  -  Base)  U 
(A  I  I  B)  LI  (B  -  Base),  where  the  operations  IJ,  Tl,  and  -  are 
interpreted  as  follows: 


1 .  a  U  b  a  v  b 

2.  a  fl  b  =>  a  a  b 

3 .  a  -  b  '==$  a  a  ~'b 


start  stop 


Figure  33.  Start  and  Stop  Timer  Operations  are  Merged  Using  a 
Flat  Lattice  Ordering  Relation. 


"PERIOD”  and  "FINISH  WITHIN"  have  integer  values  as 
conditions.  These  values  are  ordered  using  a  flat  lattice  and 
can  be  change-merged  in  the  same  way  as  described  for  Maximum 
Response  Time  and  Minimum  Calling  Period.  An  example  of  a 
control  constraint  change-merge  is  shown  in  Figure  34.  In 
this  example,  the  constraint  on  A2  does  not  appear  in  M 
because  it  appeared  in  Base  and  B,  but  not  in  A.  The 
constraints  on  A3  and  A4  appear  in  M  because  they  are  not  in 
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the  base  and  do  appear  in  one  of  the  modifications.  The 
predicate  for  the  constraint  on  A1  is  different  in  A  and  B,  so 
according  to  the  rule  above,  the  result  of  the  merge  is 
calculated  as  follows: 


y  <  0  [  y  <  0  ]  y  >  0  = 

(y  <  0  a  ~>(y  <,  0))  v  (y  <  0  a  y  ^  0)  v  (y  £  0  a  “»  (y  <  0) 
=  False  v  False  v  (y  >  0  a  (y  >  0) 
=  (y  >  0)  . 

The  "READ"  operation  appeared  in  the  change-merged 
version,  because  it  appeared  in  one  of  the  modifications,  the 
other  timer  operation  did  not  appear  in  the  merged  version, 
because  it  did  appear  in  the  base  and  in  one  of  the 
modifications,  but  not  in  the  other. 


CB...  =  CONTROL  CONSTRAINTS 

A1  TRIGGERED  IF  y  <  0 
A 2  TRIGGERED  BY  SOME  x 
START  TIMER2  IF  TRUE 
READ  TIMERl  IF  z  <  0.01 


CA  = 

CONTROL  CONSTRAINTS 

A1  TRIGGERED  IF  y  >  0 
A3  PERIOD  30  ms 


CB  = 

CONTROL  CONSTRAINTS 
A1  TRIGGERED  IF  y  <  0 
A2  TRIGGERED  BY  SOME  x 
A4  FINISH  WITHIN  20  ms 
START  TIMER2  IF  TRUE 


C*  =  CONTROL  CONSTRAINTS 

A1  TRIGGERED  IF  y  >  0 
A3  PERIOD  30  ms 
A4  FINISH  WITHIN  20  ms 
READ  TIMERl  IF  z  <  0.01 


Figur*  34.  Exaopls:  A  Msrgs  of  Control  Constraints. 
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D.  CORRECTNESS  OF  CHANGE-MERGE  OPERATION 

Thus  far,  we  have  described  a  model  which  provides  for 
separate  merging  of  specifications  and  implementations.  We 
have  demonstrated  that  for  the  individual  cases,  the  model 
either  produces  a  program  which  is  syntactically  correct  or 
provides  evidence  to  indicate  where  an  inconsistency  exists. 
There  are  still  two  things  that  need  to  be  shown.  First,  we 
must  show  that  the  change-merged  implementation  is  consistent 
and  correctly  implements  the  change-merged  specification. 
Sub-section  1,  below,  provides  a  boolean  function  Imp (Graph, 
Specification)  which  is  true  if  the  interface  of  Graph 
corresponds  to  Specification,  and  a  theorem  which  defines  the 
necessary  conditions  for  a  consistent  change-merge.  Secondly, 
we  must  discuss  the  semantic  properties  of  our  model.  These 
are  discussed  in  sub-section  2,  below. 

1 .  Consistency  of  Model 

In  developing  our  model  for  the  change-merge 
operation,  we  chose  to  handle  the  specifications  and 
implementations  separately.  This  is  beneficial  for  developing 
the  change-merge  model,  but  requires  showing  that  the 
implementation  produced  by  the  change-merge  correctly 
implements  the  change-merged  specification.  Consistency 
between  an  implementation  and  a  specification  is  defined  as 
follows : 
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Imp:  PSDL  Graph  X  PSDL  Spec  Bool 


Jmp(GA, 


SpA) 

X  G 

<=> 

iA  <=>  (X  € 

A.  S  a 

(EXT,  x)  G  A. LI) 

A 

y  € 

0A  <=>  (y  € 

A .  S  a 

(y,  EXT)  G  A.LO) 

A 

z  G 

stA  =>  (z  G 

DSa  a 

3w  G  A.  V  [  ( w,  z) 

G  A. LI) 

a  3v 

G  A. V  [  (z,  V)  G 

A.LO]  ) 

This  definition  states  that  the  graph  GA  correctly 
implements  the  specification  SpA  if  and  only  if  all  of  the 
following  are  true: 


1.  Ax  will  appear  in  the  input  set  of  the  specification  if 
and  only  if  it  appears  in  the  set  of  streams  of  the  graph, 
and  there  is  an  edge  in  the  set  of  input  links  from 

EXT  to  x. 

2.  Ay  will  appear  in  the  output  set  of  the  specification 
if  and  only  if  it  appears  in  the  set  of  streams  of  the 
graph,  and  there  is  an  edge  in  the  set  of  output  links  from 
y  to  EXT. 

3.  A  z  will  appear  in  the  set  of  states  in  the 
specification  if  and  only  if  it  appears  in  the  set  of  data 
streams  of  the  operator,  and  there  is  an  operator,  w,  in  the 
set  of  vertices  of  the  graph  such  that  there  is  an  edge  from 
w  to  z  in  the  set  of  input  links,  and  there  is  an  operator, 
v,  in  the  set  of  vertices  of  the  graph  such  that  there  is  an 
edge  in  the  set  of  output  links  from  z  to  v. 


To  show  that  the  change-merged  implementation  is 
consistent  with  its  specification,  we  provide  the  theorem  in 
Figure  35.  This  theorem  shows  that  if  the  three  input 
versions  are  consistent,  the  change-merged  version  will  be 
consistent.  Our  proof  of  this  theorem  is  contained  in 
Appendix  B. 

2 .  Semantic  Properties  of  the  Model 

The  least  common  extension  of  two  programs  provides 
the  desired  semantics  for  a  merging  operation,  but  as  was 
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THEOREM :  If  SpA,  SpBs,.  and  SpB  are  PSDL  operator 

specifications,  BA,  Bb„.  and  Bb  are  operator  graphs, 
lap  (Ba,  SpA)  ,  lap  (Bb.„,  Sp,...)  and  Iap{BB,  Sp„)  , 
then  ljnp(BA[BB„.]BB,  SpA[Sp  ]  SpB)  . 

Figure  35.  Consistency  of  Change-merge. 

pointed  out  in  [Ref.  10],  this  is  not  computable  in  the 
general  case.  We  write  the  partial  function  computed  by  an 
operator  implementation  as  F (GA)  .  Thus,  the  partial  function 
computed  by  the  resultant  implementation  of  our  change-merge 
is  F (Gm)  .  The  result  of  a  semantic  merge  on  the  three  partial 
functions,  F  (GR)  [F  (GB.#.)  ]  F  (GB)  is  written  as  FM.  The  ideal 
result  for  our  model  is:  F  (GM)  =  FM.  This  ideal  cannot  always 
be  realized  in  practice,  because  FM  is  not  computable  in  the 
general  case. 

The  best  result  that  may  be  practically  realizable 
is:  Fm  C  F(G„)  .  In  this  situation,  the  change-merge 

operation  produces  a  result  which  is  compatible  with  the  ideal 
result,  but  which  may  contain  inconsistent  values,  T,  in  some 
cases  where  an  ideal  semantic  merge  produces  a  proper  result. 
The  worst  acceptable  result  is:  F  (BM)  C  Fm.  In  this 
situation,  the  result  of  the  change-merge  is  also  compatible 
with  the  ideal  result,  but  may  diverge  in  some  cases  where  the 
semantic  merge  has  a  proper  value.  This  situation  is  less 
desirable,  because  it  cannot  be  detected  at  merge  time.  This 
result  is  the  weakest  reliable  one,  which  says  that  the  merge 
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produces  a  correct  result  whenever  it  produces  a  proper 
result.5  The  approximation  argument  given  in  [Ref.  10]  for 
two  input  merges  is  also  applicable  to  change-merges.  We  have 
discovered  that  the  result  of  the  change-merge  is  semantically 
correct  in  most  cases,  but  we  have  not  proved  correctness  in 
all  possible  cases,  so  that  complete  correctness  is  not 
guaranteed.  We  conjecture  that  the  model  satisfies  the 
property,  Vx  E  Domain  (1  *  F  (G*,)  *  T)  F  (G„)  (x)  =  FM(x), 
which  is  halfway  between  the  best  pratically  realizable 
situation  and  the  worst  acceptable  situation. 

E.  SUMMARY 

In  this  chapter,  we  hax*e  described  a  model  for  change¬ 
merging  P SDL  proarams.  This  model  divides  the  problem  into 
three  distinct  sub-problems  and  tackles  them  individually. 
What  we  have  found  is  that  when  broken  down,  these  problems 
are  relatively  simple.  Simple  set  operations  are  used  in  most 
cases  to  perform  the  change-merge  operation.  Once  the  change- 
merge  operation  is  performed,  a  consistency  check  can  be 
performed  to  ensure  that  the  change-merged  implementation 
accurately  represents  the  change-merged  specification. 
Semantically,  this  model  provides  a  correct  merge  in  most 
cases,  but  the  correct  result  is  not  guaranteed. 


5Proper  results  are  normal  data  values,  produced  by 
computations  that  terminate  cleanly. 
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IV.  CONCLUSION 


Software  is  always  changing.  Whether  the  change  is  part 
of  the  normal  evolution  process,  or  is  necessary  to  fix  a 
problem,  it  is  still  a  complicated  process.  The  larger 
software  systems  become,  the  more  complicated  making  changes 
becomes . 

A.  BENEFITS  TO  SOFTWARE  ENGINEERING 

New  methods  of  software  development  have  emerged,  such  as 
Rapid  Prototyping,  which  require  the  ability  to  quickly  create 
and  adapt  a  prototype  to  meet  the  user's  needs.  This,  in 
turn,  makes  it  necessary  to  make  changes  very  rapidly.  The 
only  way  to  effectively  make  changes  rapidly,  especially  to 
very  large  systems,  is  through  automation. 

The  need  for  automatically  making  changes  arises  when  a 
series  of  software  systems  have  been  developed  from  a  common 
base  system,  and  a  change  has  to  be  made  to  the  base.  If  an 
automated  way  of  propagating  the  change  through  all  the 
versions  is  available,  then  the  software  maintainer  will  save 
a  lot  of  time,  and  the  end  product  will  probably  have  fewer 
errors.  This  thesis  has  been  directed  at  defining  a  method 
for  doing  this  automatic  change  propagation. 
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B.  BENEFITS  TO  CAPS  RESEARCH 

The  Computer  Aided  Prototyping  System,  being  developed  at 
the  Naval  Postgraduate  School,  is  a  rapid  prototyping  system. 
The  language  used  in  CAPS,  PSDL,  is  very  adaptable  to 
automatic  change  propagation.  We  have  developed  a  model  for 
merging  three  versions  of  a  PSDL  program,  a  base  version,  and 
two  modifications.  We  call  this  three  input  merge  operation, 
"change-merging".  This  model  can  be  used,  not  only  for 
automatically  propagating  changes  through  a  series  of  software 
systems,  but  can  be  used  to  combine  the  characteristics  of  two 
different  software  systems,  which  were  developed  from  a  common 
base . 

The  model  is  effective  for  change-merging  different 
versions  of  a  common  PSDL  program,  and  we  have  shown  that  as 
long  as  the  result  of  the  change-merge  is  not  an 
inconsistency,  the  merged  implementation  will  correctly 
represent  the  merged  specification.  The  semantic  result  of 
the  change-merge  has  been  shown  to  be  correct  most  of  the 
time . 

This  model  theoretically  provides  the  ability  for  the 
engineer  writing  a  prototype,  or  a  series  of  prototypes,  to 
develop  a  change  to  the  base  version  and  press  a  button  to 
invoke  the  merging  mechanism  to  automatically  update  all 
versions  of  the  system.  It  can  also  be  used  to  automatically 
update  a  series  of  prototypes  in  the  software  base,  developed 
from  a  common  base. 
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C.  FURTHER  RESEARCH 

In  this  thesis,  we  have  provided  a  model  on  which  the 
change-merger  can  be  based  for  programs  written  in  PSDL.  Our 
work  leads  to  a  method  that  produces  correct  results  most  of 
the  time,  but  the  degree  of  correctness  has  not  been  formally 
established.  Future  work  should  classify  the  results  by  how 
close  they  come  to  an  ideal  semantic  merge,  suggest  stronger 
approximations  that  produce  results  even  closer  to  the  ideal 
semantic  merge,  and  prove  the  partial  correctness  of  the 
results . 

Eventually,  an  attempt  should  be  made  to  develop  a 
change-merger  for  Ada  code,  so  that  data  types  and  PSDL 
operators  implemented  in  Ada  code  can  be  included  in  the 
change-merger.  For  the  change-merger  to  become  a  reality  as 
currently  modelled,  a  high  level  language  description  and 
specification  must  be  developed,  and  eventually,  the  program 
must  be  coded  in  a  programming  language  such  as  Ada. 
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APPENDIX  A.  PSDL  GRAMMAR 


This  grammar  uses  standard  symbology  conventions.  {Curly 
Braces}  enclose  items  which  may  appear  zero  or  more  times. 
[Square  Brackets]  enclose  items  which  may  appear  zero  or  one 
time.  Bold  Face  items  are  terminal  keywords.  Items  contained 
in  "Double  Quotes"  are  character  literals.  The  "|"  vertical 
bar  indicates  a  list  of  options  from  which  no  more  than  one 
item  may  be  selected.  This  grammar  represents  the  current 
version  of  the  PSDL  grammar  as  of  20  June  1990. 

Start  =  psdl 
psdl  =  {component} 
component  =  data_type  |  operator 
data_type  =  type  id  type_spec  type__impl 
operator  =  operator  id  operator_spec  operator_impl 
type_spec  =  specification  [generic_param]  [type_decl] 
{operator  id  operator_spec }  [functionality]  end 
type_impl  =  implementation  ada  id  " { "  text  " } "  end 
|  implementation  type_name 
{operator  id  operator_impl }  end 
operator_spec  = 

specification  {interface}  [functionality]  end 
operator_impl  =  implementation  ada  id  " { "  text  " } " 

|  implementation  psdl_impl 
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type_decl  = 

id_list  type_name  id_list  type_name} 

functionality  =  [keywords]  [ inf ormal_des ']  [ formal_desc] 

psdl_impl  =  data_f low_diagram  [streams]  [timers] 
[control_constraints]  [iniormal_desc]  end 
type_name  =  id  | 

id  "["  actual_parameter_list  "]"  | 
id  "["  type_decl  "]" 

actual_parameter_list  =  actual_jparameter 

{  actual_parameter  } 

actualjparameter  =  type_name  i  expression 

interface  =  attribute  [ reqmt s_trace ] 

id_list  =  id  id} 

keywords  =  keywords  id_list 

informal_desc  =  description  "{"  text 

formal_desc  =  axioms  "{"  text  ” } ” 

data_f low_diagram  =  graph  {vertex}  {edge} 

streams  =  data  stream  type_decl 

timers  =  timer  id_±ist 

attribute  =  input 
I  output 
I  generic_param 
I  states 
I  exceptions 
I  timing_info 

input  =  input  type_decl 

output  =  output  type_decl 

gener ic^param  =  generic  type  decl 

states  =  states  type_decl  initially  expression  list 
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exceptions  =  exceptions  id_list 

timing_info  =  [maximum  execution  time  time] 

[minimum  calling  period  time] 

[maximum  response  time  time] 

reqmts_trace  =  by  requirements  id_list 

vertex  =  vertex  op_id  [”:"time] 

edge  =  edge  id  [":"time]  op_id  op__id 

op_id  =  id  ["("  [id_list]  " | "  [id_list]  ")"] 

control_constraints  =  control  constraints  {constraint} 

constraint  =  operator  id 

[triggered  (trigger  |  [trigger]  if  predicate) 

[ reqmts_t race ] ] 

[period  time  [reqmts__trace]  ] 

[finish  within  time  [ reqmts_trace ] ] 

{ cons traint_opt ions } 

trigger  =  by  all  id_list 
|  by  some  id__list 

const raint_opt ions  = 

output  id_list  if  predicate  [ reqmts_trace ] 

|  exception  id  [if  predicate]  [ reqmts^trace ] 

I  timer_op  id  [if  predicate]  [reqmts_trace] 

timer_op  =  read  timer 
|  reset  timer 
|  start  timer 
I  stop  timer 

expression_list  =  expression  expression} 

time  =  integer  [unit] 

unit  =  ms  |  sec  |  min  |  hours 

expression  =  constant 
I  id 

|  type_name  id  expression_list  ")" 

predicate  =  simple__expression 

|  simple_expression  rel_op  simple  expression 


simple_expression  =  [sign]  integer  [unit] 
i  [sign]  real 
!  [not]  id 
|  string 

|  [not]  "("  predicate  ")" 

|  [not]  boolean_const ant 

bool_op  =  and  |  or 

rel_op  =  "<"  |  "<="  |  ">"  |  ">="  |  "="  |  "/="  | 

real  =  integer  " . "  integer 

integer  =  digit [digit] 

boolean_constant  =  true  |  false 

numeric_constant  =  real  |  integer 

constant  =  numeric_constant  j  boolean_constant 

sign  =  "+"  | 

char  =  any  printable  character  except  "}" 

digit  =  "0  . .  9" 

letter  =  "a  . .  z”  |  "A  . .  Z"  | 

alphanumeric  =  letter  |  digit 

id  =  letter  { alphanumeric  ] 

string  =  . .  text  """ 

text  =  {char} 
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APPENDIX  B.  PROOF:  CONSISTENCY  OF  CHANGE-MERGE  THEOREM 


This  appendix  contains  the  proof  of  our  Consistency  of 
Change-merge  theorem  in  Chapter  III,  Figure  35. 

PROOF : 

Let  M  =  A[Base]B  be  the  result  '.nt  operator  after  a 
change-merge  operation. 

Assume:  Iap(GK,  SpA)  ,  Xnp(G8...,  SpB„.)  and  Xinp(GB,  Sp8)  . 

Need  to  Show:  Jxnp(GM,  SpM)  . 


Assume  x  £  IM,  y 

€ 

0M, 

and 

z  £  stM 

Need  to  Show  A. 

(-•< 

€ 

M.S  a 

(EXT,  :<) 

£ 

M.LI) 

B. 

<y 

£ 

M.S  a 

(y, EXT) 

£ 

M.LO) 

C  . 

(z 

£ 

dsm  a 

3  w  £  m  . 

V 

[  (w,  z)  £  M.LI] 

a  3v  £  M.V  [( z,v )  £  M.LO] 


A.  There  are  two  possibilities:  x  £  IB„..  and  *"Mx  £  IBs„)  . 

Case  1 :  x  £  IB„. 

Then  by  definition  of  change-merge,  x  £  IA  a  x  £  IB. 

Since  Imp( GB.„,  SpB.„)  ,  Imp  ( GA,  SpA)  and  Imp  ( GB ,  SpB)  , 

Then  x  £  Base.S  a  (EXT,x)  £  Base. LI)  a 

x  £  A . S  a  (EXT , x)  £  A. LI)  a 

X  £  B.S  a  (EXT , x)  £  B.LI) 

And  by  definition  of  change-merge 

x  £  M.S  a  (EXT, x)  £  M.LI)  (A.) 


Case  2 : 


“•U  €  iB„.) 


Then  by  definition  of  change-merge,  x  G  IA  „•  x  G  IB. 

Since  Imp  <GB„.,  SpB„.)  ,  Xjqp(GA,  SpA)  and  Xmp(GB,  SpB)  , 

Then  ~~l  (x  G  Base.S  a  (EXT,x)  G  Base. LI))  a 
((x  G  A . S  a  (EXT, x)  G  A. LI)  v 

(x  G  B.S  a  (EXT, x)  G  B . LI ) ) 

Since  (EXT,  x)  G  Base. LI  ==$  x  G  Base.S 

Then  x  G  Base.S  a  (EXT,x)  G  Base.  LI 
(EXT , x)  G  Base. LI 

Thus  “•  (x  G  Base.S  a  (EXT,  x)  G  Base. LI))  <J=i> 

(EXT ,  x)  G  Base.  LI 

Thus  (EXT , x)  G  A. LI  v  (EXT,x)  G  B.LI 

And  x  G  A.S  .  x  G  B.S 

And  by  definition  of  change-merge 

x  G  M.S  a  (EXT, x)  G  M.LI)  (A.) 

B.  There  are  two  possibilities:  y  G  0B„.  and  (y  G  0B.,J 
Case  1  :  y  G  0B.„ 

Then  by  definition  of  change-merge,  y  G  0A  r  y  G  0„. 

Since  Xay(GB.„,  SpB.„)  ,  Xfl¥>(GA,  SpA)  and  Xxnp(GB,  SpB)  , 

Then  y  G  Base.S  a  (y, EXT)  G  Base.LO)  a 
y  G  A.S  a  (y, EXT)  G  A.LO)  a 

y  G  B.S  a  (y, EXT)  G  B.LO) 

And  by  definition  of  change-merge 

y  G  M.S  a  (y, EXT)  G  M.LO)  (B . ) 
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Case  2:  “•  (y  E  0B.„) 

Then  by  definition  of  change-merge,  y  E  0A  v  y  E  0B . 

Since  Xinp(GB...,  SpB..J  ,  Xap(GA,  SpA)  and  X«p(GB,  SpB)  , 

Then  (y  E  Base.S  a  (y, EXT)  E  Base.LO))  a 
(  (y  E  A.S  a  (y, EXT)  E  A.LO)  v 
(y  E  B.S  a  (y, EXT)  E  B.LO)) 

Since  (y,  EXT)  E  Base.LO  =>  y  E  Base..- 

Then  y  E  Base.S  a  (y, EXT)  E  Base.LO 
(y, EXT)  E  Base.LO 

Thus  (y  E  Base.S  a  (y,EXT)  E  Base.LO)) 

(y,  EXT)  E  Base.LO 

Thus  (y, EXT )  E  A.LO  ^  (y, EXT)  E  B.LO 

And  yE  A.S  v  y  E  B.S 

And  by  definition  of  change-merge 

y  E  M.S  a  (y, EXT)  E  M.LO)  (B . ) 

C.  There  are  two  possibilities:  z  E  StB„.  and  ( z  E  St8ll,,)  . 

Case  1 :  z  E  StB... 

Then  by  definition  of  change-merge,  z  E  StA  •  z  E  StB. 

Since  Xxnp(GB.„,  SpB„.)  ,  Xmp<GA,  SpA)  and  Xinp(GB,  SpB)  , 

Then  (z  E  DSBa„  a  3w  E  Base.V  [(w,  z)  E  Base. LI] 

a  3v  E  Base.V  [(z,  v)  E  Base.LO])  a 
(z  E  DSa  a  3k  E  A.V  [  (  k,  z)  E  A. LI] 

a  3v  E  A.V  [ (z,  r)  E  A.LO])  a 
(z  E  DSb  a  3k  E  B.V  [(k,  z)  E  B.LIJ 
A  3v  E  B.V  [(z,  v)  E  B.LO]) 


76 


And  by  definition  of  change-merge 

(z  G  DSm  a  3w  G  M.V  [(w,  z)  G  M.LI] 

A  3v  G  M.V  [(Z,  v)  G  M .  LO  ]  )  (C.) 


Case  2: 


<z  G  StB..J 


Then  by  definition  of  change-merge,  z  G  StA  v  z  G  StB 

Since  Jjap(GBa„,  SpB.„)  ,  Imp(Gk,  SpJ  and  Imp(GB,  SpB)  , 

Then  “,(z  G  DSB,„  a  3w  G  Base.V  [(w,  z)  G  Base. LI] 

a  3v  G  Base.V  [ (z,  v)  G  Base.LO]) 
((z  G  DSa  A  3w  G  A.V  [  (v,  z)  G  A. LI] 

a  3v  G  A.V  [(z,  v)  G  A.LO])  j 
(z  G  DSb  a  3 w  G  B.V  [(w,  z)  G  B.LI] 

A  3v  G  B.V  [<Z,  v)  G  B .  LO  ]  )  ) 

And  by  definition  of  change-merge 

(z  G  DS„  a  3w  G  M.V  [  (hr,  z)  G  M.LI] 

a  3v  G  M.V  f  (z,  v)  G  M.  LO]  )  (C.) 

Therefore  by  A,  B,  and  C  we  conclude 

x  G  IM  =>  (x  G  M.S  ■  (EXT,  x)  G  M.LI)  ■ 

y  G  0M  (y  G  M.S  a  (y,  EXT)  G  M.LO)  a 

z  G  StM  — (zG  DSma3wG  M.V  [(w,  z)  G  M.LI] 

A  3v  G  M.V  [(z,  v)  G  M.LO] 


(<=) 


Assume  (x  G  M.S  a  (EXT,  x)  G  M.LI)  and 
(y  G  M.S  a  (y,  EXT)  G  M.LO) 

Need  to  Show  D.  x  G  IM 
E.  y  G  0M 
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D.  There  are  two  possibilities: 

x  E  Base.S  a  (EXT,x)  E  Base. LI  and 
“Mx  E  Base.S  a  (EXT,x)  E  Base. LI). 

Case  1:  x  E  Base.S  a  (EXT,x)  E  Base. LI 

Then  by  definition  of  change-merge, 
x  E  A. S  a  (EXT, x)  E  A. LI  a 
x  E  B.S  a  (EXT, x)  E  B.LI 

Since  lap  (GB...,  SpB..J  ,  Imp  (GA,  SpA)  and  lap  (G„,  SpB)  , 

*  £  Is...  a  x  E  IA  A  x  E  IB 

And  by  definition  of  change-merge,  x  E  IM.  (D .  ) 

Case  2:  —1(x  E  Base.S  a  (EXT,x)  E  Base. LI) 

Since  (EXT,x)  E  Base. LI  x  E  Base.S 

Then  x  E  Base.S  a  (EXT,x)  E  Base. LI 
(EXT,  x)  E  Base.  LI 

Thus  “’(x  E  Base.S  a  (EXT,x)  E  Base. LI))  <£=> 

“ ’  (EXT , x)  E  Base. LI 

Thus  (EXT, x)  E  A. LI  v  (EXT, x)  E  B.LI 

And  xE  A.SvxE  B.S 

Then  x  E  A.S  a  (EXT,x)  E  A. LI  v 
x  E  B.S  a  (EXT, x)  E  B.LI 

Since  lap  (G„„.,  SpB...)  ,  Jap(GA,SpA)  and  Imp  ( G, ,  SpB )  , 

“Mx  E  iB„.)  a  (x  E  iA  v  x  E  iB) 

And  by  definition  of  change-merge,  x  E  IM.  (D.) 
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E.  There  are  two  possibilities: 

y  G  Base.S  a  (y, EXT)  G  Base.LO  and 
“My  G  Base.S  a  (y,  EXT)  G  Base.LO). 

Case  1:  y  G  Base.S  a  (y,EXT)  G  Base.LO 

Then  by  definition  of  change-merge, 
y  G  A . S  a  (y, EXT)  G  A.LO  a 
y  G  B.S  a  (y, EXT)  G  B . LO 

Since  lap  Sp8„.)  ,  Jmp  <GX,  SpA)  and  lap  <G„  SpB)  , 

V  ^  Is...  a  y  G  I*  a  y  G  I, 

And  by  definition  of  change-merge,  y  G  IM.  (E.) 

Case  2:  “My  £  Base.S  a  (y,  EXT)  G  Base.LO) 

Since  (y,EXT)  G  Base.LO  y  G  Base.S 

Then  y  G  Base.S  a  (y, EXT)  G  Base.LO 
(y, EXT)  G  Base.LO 

Thus  “My  G  Base.S  a  (y, EXT)  G  Base.LO))  <=> 

“My,  EXT)  G  Base.LO 

Thus  (y, EXT)  G  A.LO  v  (y,  EXT)  G  B . LO 

And  y  G  A.S  *  y  G  B.S 

Then  y  G  A.S  a  (y, EXT)  G  A.LO  - 
y  G  B.S  a  (y, EXT)  G  B . LO 

Since  Imp  (GB.„,  Sp,„.)  ,  Imp  (Gk,  SpA)  and  Imp  (GB,  SpB)  , 

”,<y  €  IB..J  A  (y  G  I,  V  y  G  IB) 

And  by  definition  of  change-merge,  y  G  1M.  (E.) 
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Therefore  by  D  and  E  we  conclude 

(x  G  M.S  a  (EXT,  x)  G  M.LI)  x  G  IM  a 

(y  G  M.S  a  (y,  EXT)  G  M.LO)  =>  y  G  0M 

Therefore  By  (=?>)  and  C^),  Imp(GH,  SpM)  .  D 
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GLOSSARY 


Approximates  -  A  program  P  approximates  another  program  Q  if 
P  is  defined  everywhere  that  Q  is  defined.  Q  may  or  may  not 
be  defined  in  places  where  P  is  undefined. 

Bipartite  -  A  bipartite  graph  is  a  graph  in  which  the 
vertices  can  be  divided  into  distinct  sets,  where  there  exists 
no  edge  from  one  vertex  to  another  within  the  same  set. 

Computer-Aided  Prototyping  System (CAPS)  -  This  system  is 
being  developed  by  Dr.  Berzins  and  Dr.  Luqi  at  the  Naval 
Postgraduate  School  for  use  in  Rapid  Prototyping  of  Real-Time 
Systems . 

CPU  -  Central  Processor  Unit 

Directed  Acyclic  Graph (DAG)  -  It  is  a  graph  which  contains 
directed  edges  and  no  cycles . 

Feasible  -  Any  PDG  Gp  is  feasible  if  it  is  a  PDG  for  a 
program  P.  The  slice  G/S  is  feasible  if  S  c  V(G)  and  G  is 
feasible . 

FIFO  -  First  In  First  Out. 

Greatest  Common  Approximation  -  The  greatest  common 
approximation  of  two  programs  is  considered  to  be  a  program 
which  approximates  both  programs  and  contains  all  of  the 
functionality  common  to  both  programs. 

Least  Common  Extension  -  The  least  common  extension  of  two 
programs  is  the  result  of  merging  the  functionality  contained 
in  both  programs.  Both  input  programs  approximate  the  least 
common  extension. 

Program  Dependence  Graph (PDG)  -  Used  by  Horwitz  et  al .  to 
abstractly  represent  programs.  It  consists  of  a  set  of 
vertices  and  a  set  of  edges  which  link  these  vertices.  The 
vertices  represent  operations  performed  in  the  program,  and 
the  edges  represent  control  flow  and  data  flow  dependences 
between  those  operations. 

Prototyping  System  Description  Language (PSDL)  -  Rapid 
prototyping  language  developed  by  Dr.  Luqi  at  the  Naval 
Postgraduate  School  for  use  in  designing  prototypes  within  the 
CAPS  system. 


Software  Maintenance  -  All  activities  performed  on  a  software 
system  during  its  life  time  to  enhance  or  repair  the  system. 

Software  Manufacture  -  The  combining  of  primitive  components 
of  a  software  system,  through  a  sequence  of  derivations,  into 
one  or  more  software  products. 
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